OpenID Connect · OAuth 2.0
Les flows en diagrammes
Qui parle à qui, dans quel ordre. Les traits pleins sont des requêtes, les pointillés des réponses. Pour choisir, commencez par Quel flow choisir ?
Authorization Code + PKCE · Hybride (code id_token, code token…) · Implicit (id_token, id_token token) · Refresh Token · Client Credentials · Mot de passe (ROPC) · Device Code (RFC 8628) · Échange de jeton (RFC 8693) · Déconnexion (RP-initiated et back-channel) · Introspection et révocation · private_key_jwt et JWT Bearer (RFC 7523) · PAR et JAR (RFC 9126 et 9101) · JARM (réponse d’autorisation signée) · DPoP (RFC 9449) · CIBA (Client-Initiated Backchannel)
Authorization Code + PKCE Recommandé
Le flow standard : le navigateur ne voit qu’un code à usage unique, les jetons passent de serveur à serveur.
Navigateur Application Fournisseur (OP) API 1. Génère code_verifier, state, nonce 2. 302 vers /authorize (challenge, state, nonce) 3. GET /authorize 4. Page de connexion et de consentement 5. Identifiants et accord de la personne 6. 302 redirect_uri?code=…&state=… 7. GET /callback?code=…&state=… 8. POST /token (code, code_verifier, secret) 9. ID token + access token (+ refresh token) 10. Vérifie signature, iss, aud, nonce 11. Authorization: Bearer access_token 12. Données demandées Version texte du diagramme Application : Génère code_verifier, state, nonce Application → Navigateur : 302 vers /authorize (challenge, state, nonce) Navigateur → Fournisseur (OP) : GET /authorize Fournisseur (OP) → Navigateur : Page de connexion et de consentement Navigateur → Fournisseur (OP) : Identifiants et accord de la personne Fournisseur (OP) → Navigateur : 302 redirect_uri?code=…&state=… Navigateur → Application : GET /callback?code=…&state=… Application → Fournisseur (OP) : POST /token (code, code_verifier, secret) Fournisseur (OP) → Application : ID token + access token (+ refresh token) Application : Vérifie signature, iss, aud, nonce Application → API : Authorization: Bearer access_token API → Application : Données demandées À utiliser quand : Tout site web, application mobile, SPA ou application de bureau où une personne se connecte.
Ce qui le distingue : C’est la base. Tous les autres flows en sont une variante ou un cas particulier.
ID-Kit sait le jouer : fournisseur de test (votre application contre ID-Kit) et application de test (votre fournisseur contre ID-Kit).
Hybride (code id_token, code token…) Cas précis
On reçoit l’identité tout de suite dans le navigateur, et le code pour obtenir les jetons sûrement.
Navigateur Application Fournisseur (OP) 1. 302 vers /authorize (response_type=code id_token) 2. GET /authorize puis connexion 3. 302 redirect_uri#code=…&id_token=…&state=… 4. Un script lit le fragment et le renvoie 5. POST /callback (code, id_token, state) 6. Vérifie id_token et c_hash 7. POST /token (code, code_verifier) 8. access token (+ refresh token) Version texte du diagramme Application → Navigateur : 302 vers /authorize (response_type=code id_token) Navigateur → Fournisseur (OP) : GET /authorize puis connexion Fournisseur (OP) → Navigateur : 302 redirect_uri#code=…&id_token=…&state=… Navigateur : Un script lit le fragment et le renvoie Navigateur → Application : POST /callback (code, id_token, state) Application : Vérifie id_token et c_hash Application → Fournisseur (OP) : POST /token (code, code_verifier) Fournisseur (OP) → Application : access token (+ refresh token) À utiliser quand : Une application qui doit connaître la personne avant d’échanger le code (validation de session côté serveur, anciennes bibliothèques).
Ce qui le distingue : Comme le code, mais l’ID token arrive dès la redirection (avec c_hash qui le lie au code).
ID-Kit sait le jouer : fournisseur de test (votre application contre ID-Kit) et application de test (votre fournisseur contre ID-Kit).
Implicit (id_token, id_token token) Déconseillé
Les jetons arrivent directement dans l’adresse : plus simple, mais exposé.
Navigateur (SPA) Fournisseur (OP) API 1. Génère state et nonce 2. GET /authorize (response_type=id_token token) 3. 302 redirect_uri#id_token=…&access_token=… 4. Lit le fragment, vérifie le jeton 5. Authorization: Bearer access_token Version texte du diagramme Navigateur (SPA) : Génère state et nonce Navigateur (SPA) → Fournisseur (OP) : GET /authorize (response_type=id_token token) Fournisseur (OP) → Navigateur (SPA) : 302 redirect_uri#id_token=…&access_token=… Navigateur (SPA) : Lit le fragment, vérifie le jeton Navigateur (SPA) → API : Authorization: Bearer access_token À utiliser quand : Presque jamais. Seulement pour de vieilles SPA ou pour vérifier qu’une application l’interdit bien.
Ce qui le distingue : Aucun échange de code : pas de canal arrière, pas de refresh token, jetons visibles de l’historique du navigateur.
ID-Kit sait le jouer : fournisseur de test (votre application contre ID-Kit) et application de test (votre fournisseur contre ID-Kit).
Refresh Token Complément
Renouveler un access token qui vit peu, sans redemander la personne.
Application Fournisseur (OP) API 1. Authorization: Bearer access_token 2. 401 invalid_token (expiré) 3. POST /token (grant_type=refresh_token) 4. Révoque l’ancien refresh token (rotation) 5. Nouvel access token + nouveau refresh token 6. Authorization: Bearer nouvel access_token Si l’ancien refresh token est rejoué, toute la famille de jetons est révoquée. Version texte du diagramme Application → API : Authorization: Bearer access_token API → Application : 401 invalid_token (expiré) Application → Fournisseur (OP) : POST /token (grant_type=refresh_token) Fournisseur (OP) : Révoque l’ancien refresh token (rotation) Fournisseur (OP) → Application : Nouvel access token + nouveau refresh token Application → API : Authorization: Bearer nouvel access_token À utiliser quand : Dès que vous voulez des access tokens courts tout en gardant la personne connectée longtemps (scope offline_access).
Ce qui le distingue : Ce n’est pas un flow de connexion : il prolonge une session obtenue avec un autre flow.
ID-Kit sait le jouer : fournisseur de test (votre application contre ID-Kit) et application de test (votre fournisseur contre ID-Kit).
Client Credentials Machine à machine
Pas de personne : le service s’authentifie avec son secret.
Service Fournisseur (OP) API 1. POST /token (grant_type=client_credentials, scope) 2. Vérifie le secret du client 3. access token 4. Authorization: Bearer access_token 5. Données Version texte du diagramme Service → Fournisseur (OP) : POST /token (grant_type=client_credentials, scope) Fournisseur (OP) : Vérifie le secret du client Fournisseur (OP) → Service : access token Service → API : Authorization: Bearer access_token API → Service : Données À utiliser quand : Un service, une tâche planifiée ou un démon qui appelle une API en son nom propre.
Ce qui le distingue : Aucun navigateur, aucun ID token, aucun refresh token : seulement un access token limité aux scopes du client.
ID-Kit sait le jouer : fournisseur de test (votre application contre ID-Kit) et application de test (votre fournisseur contre ID-Kit).
Mot de passe (ROPC) À éviter
L’application recueille elle-même le mot de passe et l’envoie au fournisseur.
Personne Application Fournisseur (OP) 1. Saisit identifiant et mot de passe 2. POST /token (grant_type=password, username, password) 3. access token (+ refresh token) ou erreur Version texte du diagramme Personne → Application : Saisit identifiant et mot de passe Application → Fournisseur (OP) : POST /token (grant_type=password, username, password) Fournisseur (OP) → Application : access token (+ refresh token) ou erreur À utiliser quand : À éviter. Seulement pour une migration depuis un ancien système ou des tests automatisés.
Ce qui le distingue : Contourne la page du fournisseur : pas de MFA, pas de SSO, hameçonnage facilité.
ID-Kit sait le jouer : fournisseur de test (votre application contre ID-Kit) et application de test (votre fournisseur contre ID-Kit).
Device Code (RFC 8628) Appareils sans navigateur
L’appareil affiche un court code ; la personne le valide sur son téléphone.
Appareil Fournisseur (OP) Téléphone / ordinateur 1. POST /device_authorization 2. device_code, user_code, adresse 3. Affiche « allez sur … et saisissez ABCD-EFGH » 4. Ouvre l’adresse, saisit le code, se connecte 5. POST /token (device_code) en boucle 6. authorization_pending, puis les jetons Version texte du diagramme Appareil → Fournisseur (OP) : POST /device_authorization Fournisseur (OP) → Appareil : device_code, user_code, adresse Appareil : Affiche « allez sur … et saisissez ABCD-EFGH » Téléphone / ordinateur → Fournisseur (OP) : Ouvre l’adresse, saisit le code, se connecte Appareil → Fournisseur (OP) : POST /token (device_code) en boucle Fournisseur (OP) → Appareil : authorization_pending, puis les jetons À utiliser quand : Télévision, console, objet connecté, outil en ligne de commande.
Ce qui le distingue : La connexion se fait sur un autre appareil. L’appareil interroge le fournisseur jusqu’à validation.
ID-Kit sait le jouer : fournisseur de test (votre application contre ID-Kit) et application de test (votre fournisseur contre ID-Kit).
Échange de jeton (RFC 8693) Cas précis
Échanger un jeton contre un autre, pour un autre destinataire.
API A Fournisseur (OP) API B 1. POST /token (grant_type=token-exchange, subject_token, audience=B) 2. Contrôle droits et audience 3. access token pour l’API B 4. Authorization: Bearer nouveau jeton Version texte du diagramme API A → Fournisseur (OP) : POST /token (grant_type=token-exchange, subject_token, audience=B) Fournisseur (OP) : Contrôle droits et audience Fournisseur (OP) → API A : access token pour l’API B API A → API B : Authorization: Bearer nouveau jeton À utiliser quand : Une API qui doit en appeler une autre au nom de la personne, ou des microservices qui propagent l’identité.
Ce qui le distingue : Part d’un jeton déjà obtenu, sans nouvelle connexion. Peut réduire les droits ou changer l’audience.
ID-Kit sait le jouer : fournisseur de test (votre application contre ID-Kit) et application de test (votre fournisseur contre ID-Kit).
Déconnexion (RP-initiated et back-channel) Session
Fermer la session chez le fournisseur et prévenir les autres applications.
Navigateur Application A Fournisseur (OP) Application B 1. Clique sur « Se déconnecter » 2. 302 vers /logout (id_token_hint, post_logout_redirect_uri) 3. GET /logout 4. Ferme la session du fournisseur 5. POST logout_token (back-channel) 6. 302 vers post_logout_redirect_uri Version texte du diagramme Navigateur → Application A : Clique sur « Se déconnecter » Application A → Navigateur : 302 vers /logout (id_token_hint, post_logout_redirect_uri) Navigateur → Fournisseur (OP) : GET /logout Fournisseur (OP) : Ferme la session du fournisseur Fournisseur (OP) → Application B : POST logout_token (back-channel) Fournisseur (OP) → Navigateur : 302 vers post_logout_redirect_uri À utiliser quand : Toute application avec connexion unique (SSO) : la déconnexion doit se propager.
Ce qui le distingue : Le back-channel prévient par serveur à serveur, sans passer par le navigateur (donc fiable).
ID-Kit sait le jouer : fournisseur de test (votre application contre ID-Kit) et application de test (votre fournisseur contre ID-Kit).
Introspection et révocation Contrôle
Demander au fournisseur si un jeton est encore valable, ou l’invalider.
API Fournisseur (OP) 1. POST /introspect (token) 2. { "active": true, scope, exp, sub } 3. POST /revoke (token) 4. 200 : le jeton est invalide Version texte du diagramme API → Fournisseur (OP) : POST /introspect (token) Fournisseur (OP) → API : { "active": true, scope, exp, sub } API → Fournisseur (OP) : POST /revoke (token) Fournisseur (OP) → API : 200 : le jeton est invalide À utiliser quand : Une API qui reçoit un jeton opaque, ou qui veut une révocation immédiate.
Ce qui le distingue : Un JWT se vérifie seul par sa signature ; un jeton opaque exige cet appel.
ID-Kit sait le jouer : fournisseur de test (votre application contre ID-Kit) et application de test (votre fournisseur contre ID-Kit).
private_key_jwt et JWT Bearer (RFC 7523) Dans ID-Kit : fournisseur de test
Le client prouve son identité avec un JWT signé par sa clé privée, plutôt qu’avec un secret partagé.
Service Fournisseur (OP) 1. Signe un JWT (iss, sub, aud, exp, jti) 2. POST /token (client_assertion, client_assertion_type) 3. Vérifie la signature avec la clé publique du client 4. access token Version texte du diagramme Service : Signe un JWT (iss, sub, aud, exp, jti) Service → Fournisseur (OP) : POST /token (client_assertion, client_assertion_type) Fournisseur (OP) : Vérifie la signature avec la clé publique du client Fournisseur (OP) → Service : access token À utiliser quand : Banque, santé, API sensibles, intégrations d’entreprise : aucun secret à stocker ni à faire tourner.
Ce qui le distingue : Même échange que client credentials, mais l’authentification est une assertion signée (client_assertion).
ID-Kit sait le jouer côté fournisseur de test (déclarez la clé publique de votre client, type « Confidentiel par clé »). Pas encore côté application de test.
PAR et JAR (RFC 9126 et 9101) Dans ID-Kit
La demande d’autorisation est déposée de serveur à serveur, au lieu de passer en clair dans l’adresse.
Navigateur Application Fournisseur (OP) 1. POST /par (tous les paramètres, signés) 2. request_uri (valable quelques secondes) 3. 302 vers /authorize?request_uri=… 4. GET /authorize?request_uri=… 5. Connexion puis redirection avec le code Version texte du diagramme Application → Fournisseur (OP) : POST /par (tous les paramètres, signés) Fournisseur (OP) → Application : request_uri (valable quelques secondes) Application → Navigateur : 302 vers /authorize?request_uri=… Navigateur → Fournisseur (OP) : GET /authorize?request_uri=… Fournisseur (OP) → Navigateur : Connexion puis redirection avec le code À utiliser quand : Exigences FAPI : empêcher qu’un paramètre soit modifié ou lu dans le navigateur.
Ce qui le distingue : Le navigateur ne porte plus qu’un request_uri opaque.
ID-Kit sait le jouer : fournisseur de test (votre application contre ID-Kit) et application de test (votre fournisseur contre ID-Kit).
JARM (réponse d’autorisation signée) Dans ID-Kit (fournisseur de test)
Le fournisseur signe aussi sa réponse : le code arrive dans un JWT, pas en clair dans l’adresse.
Navigateur Application Fournisseur (OP) 1. 302 vers /authorize?response_mode=jwt 2. GET /authorize puis connexion 3. Signe un JWT { iss, aud, code, state } 4. Redirection vers l’application ?response=JWT 5. Transmet response 6. Vérifie la signature, iss, aud, puis lit le code Version texte du diagramme Application → Navigateur : 302 vers /authorize?response_mode=jwt Navigateur → Fournisseur (OP) : GET /authorize puis connexion Fournisseur (OP) : Signe un JWT { iss, aud, code, state } Fournisseur (OP) → Navigateur : Redirection vers l’application ?response=JWT Navigateur → Application : Transmet response Application : Vérifie la signature, iss, aud, puis lit le code À utiliser quand : FAPI 2.0, secteurs réglementés, protection contre les attaques de mélange entre fournisseurs.
Ce qui le distingue : Un seul paramètre « response » (JWT signé avec iss, aud, exp, code, state) remplace les paramètres en clair.
ID-Kit sait le jouer côté fournisseur de test (déclarez la clé publique de votre client, type « Confidentiel par clé »). Pas encore côté application de test.
DPoP (RFC 9449) Dans ID-Kit (fournisseur de test)
Le jeton est lié à une clé que seul le client possède : un jeton volé est inutilisable.
Application Fournisseur (OP) API 1. Crée une paire de clés 2. POST /token + en-tête DPoP (preuve signée) 3. access token lié à la clé (cnf.jkt) 4. Authorization: DPoP jeton + nouvelle preuve DPoP 5. Vérifie la preuve et le lien avec la clé Version texte du diagramme Application : Crée une paire de clés Application → Fournisseur (OP) : POST /token + en-tête DPoP (preuve signée) Fournisseur (OP) → Application : access token lié à la clé (cnf.jkt) Application → API : Authorization: DPoP jeton + nouvelle preuve DPoP API : Vérifie la preuve et le lien avec la clé À utiliser quand : Haute sécurité, SPA exposées, API sensibles.
Ce qui le distingue : Chaque appel est accompagné d’une preuve signée (en-tête DPoP) prouvant la possession de la clé.
ID-Kit sait le jouer côté fournisseur de test (déclarez la clé publique de votre client, type « Confidentiel par clé »). Pas encore côté application de test.
CIBA (Client-Initiated Backchannel) Dans ID-Kit (fournisseur de test)
L’authentification se fait sur l’appareil de la personne, à l’initiative du serveur.
Application Fournisseur (OP) Téléphone 1. POST /bc-authorize (login_hint, binding_message) 2. auth_req_id 3. Notification : « Autoriser ce paiement ? » 4. La personne accepte 5. POST /token (auth_req_id) en boucle, ou rappel 6. Jetons Version texte du diagramme Application → Fournisseur (OP) : POST /bc-authorize (login_hint, binding_message) Fournisseur (OP) → Application : auth_req_id Fournisseur (OP) → Téléphone : Notification : « Autoriser ce paiement ? » Téléphone → Fournisseur (OP) : La personne accepte Application → Fournisseur (OP) : POST /token (auth_req_id) en boucle, ou rappel Fournisseur (OP) → Application : Jetons À utiliser quand : Centre d’appels, banque, validation d’un paiement par notification.
Ce qui le distingue : Aucune redirection du navigateur : le fournisseur sollicite directement la personne.
ID-Kit sait le jouer côté fournisseur de test (déclarez la clé publique de votre client, type « Confidentiel par clé »). Pas encore côté application de test.
