Sécurité et mise en production

Checklist à valider avant d'ouvrir l'intégration à de vrais utilisateurs.

Cette liste regroupe les points qui, dans nos échanges avec les RP, causent le plus de failles ou d’incidents. Cochez chaque ligne avant de demander l’accès de production.

Secrets

• Le client_secret et la clé de signature webhook sont dans un gestionnaire de secrets ou des variables d’environnement, jamais dans le dépôt Git, ni dans un front-end, une application mobile, un ticket ou un message.
• Ils n’apparaissent dans aucun log, ni dans les traces d’erreur (attention aux print(response.text) et aux dumps de configuration).
• Vous savez les renouveler (secret : demande à A3BC ; clé webhook : versionnée v1/v2, gardez les deux pendant la bascule).
• Les secrets de sandbox et de production sont différents.

Redirection et flux

• La redirect_uri est en HTTPS en production et strictement identique à celle enregistrée.
• state est généré aléatoirement, lié à la session de l’utilisateur, comparé au retour, puis supprimé.
• nonce est généré aléatoirement, lié à la session, comparé au claim nonce de l’id_token.
• L’échange du code se fait côté serveur uniquement.
• Les paramètres error / error_description du retour sont gérés avec un message clair à l’utilisateur.

Jetons et claims

• La signature de l’id_token est vérifiée, avec iss, aud (votre client_id) et exp.
• Les jetons d’accès ne sont jamais placés dans une URL, un cookie accessible au navigateur, ni un log.
• Les claims utiles sont stockés dès réception (l’accès n’est garanti que 30 minutes).
• Le code gère un claim absent, vide (credential en attente) et non vérifié (*_verified), voir Lire les claims.
• Les dates d’expiration des credentials (*.credential.expiration) sont contrôlées quand votre cas d’usage l’exige.
• Vous utilisez sub comme identifiant utilisateur, pas l’e-mail ni le nom.

Données personnelles

• Vous ne demandez que les scopes strictement nécessaires ; les scopes sensibles sont justifiés.
• Les documents (pièce d’identité…) sont stockés chiffrés, avec une durée de conservation définie, et supprimés quand elle est atteinte.
• Un événement delayed_sharing.revoke déclenche vos règles de suppression ou d’anonymisation.
• Les logs ne contiennent aucune donnée personnelle (nom, date de naissance, numéro de sécurité sociale, contenu de documents).
• Votre DPO ou votre conseil juridique a validé le traitement (base légale, information des personnes, registre).

Webhook

• L’endpoint est en HTTPS et public.
• La signature est vérifiée sur le corps brut, avant tout parsing, avec comparaison à temps constant ; la clé est décodée de base64.
• Un événement signé de façon invalide reçoit 401 et n’est pas traité.
• L’endpoint répond en moins de quelques secondes (204) et traite en tâche de fond.
• Les événements sont dédupliqués sur id, dans un stockage persistant avec expiration.
• Le traitement est idempotent : le rejouer ne casse rien.

Résilience

• Tous les appels sortants ont un timeout.
• Les erreurs de l’API de partage différé sont traitées par code : retry (avec délai croissant) uniquement sur 00001 et 00010, aucun sur les autres.
• Le discovery et le JWKS sont mis en cache, avec rechargement du JWKS si la clé de signature change.
• Une alerte existe sur les échecs de connexion, de signature et de webhook.

Passage en production

• Nouvelle demande d’accès pour l’environnement de production : nouveaux client_id, client_secret, URL de callback et de webhook.
• Les URL de production (communiquées par A3BC) remplacent celles de la sandbox, par configuration, sans modifier le code.
• Un test de bout en bout a été joué en sandbox, y compris : consentement refusé, state invalide, webhook rejoué, signature invalide, consentement révoqué.