OpenID Connect

OAuth pour l’autorisation, OIDC pour l’authentification

OAuth 2.0 répond à une seule question : cette application est-elle autorisée à agir au nom de cet utilisateur ? Il délivre des jetons d’accès (access tokens) pour les API. Par conception, il ne dit rien sur l’identité de l’utilisateur. Ce manque a causé des années de confusion, et OpenID Connect est la solution.

OpenID Connect est une légère couche d’identité ajoutée par-dessus OAuth 2.0. Il standardise le flux de connexion, définit un ID token qui atteste de l’identité, et publie des métadonnées pour que les clients puissent être configurés sans tâtonnements. Lorsque vous cliquez sur « Se connecter avec Google » ou sur un bouton SSO d’entreprise, vous utilisez OIDC.

La règle pratique : si vous avez besoin de savoir qui est l’utilisateur, utilisez OIDC. Si vous avez besoin qu’une application effectue une action en son nom, utilisez OAuth. La plupart des systèmes de connexion nécessitent les deux, c’est pourquoi ils sont généralement déployés ensemble.

Le jeton ID (ID token)

L’élément central d’OIDC est l’ID token : un JWT signé par le fournisseur d’identité. Il contient les claims dont votre application a besoin pour établir une session.

• sub — l’identifiant stable et unique de l’utilisateur.
• iss — l’émetteur (issuer), pour savoir quel fournisseur l’a signé.
• aud — le client id pour lequel il a été émis ; un jeton destiné à une autre application doit être rejeté.
• exp et iat — la date d’expiration et la date d’émission.
• nonce — reprend la valeur que vous avez envoyée, afin de lier le jeton à cette tentative de connexion.
• email, name, picture — les claims de profil, lorsque les scopes demandés le permettent.

L’ID token est destiné à votre client. Ce n’est pas l’identifiant que vous envoyez aux API en aval — c’est le rôle de l’access token. Maintenir cette distinction permet d’éviter une erreur de conception courante.

Découverte

Chaque fournisseur conforme publie un document de découverte :

https://accounts.example.com/.well-known/openid-configuration

Celui-ci liste les points de terminaison (endpoints) d’autorisation, de token, d’userinfo et de JWKS, ainsi que les scopes et les algorithmes supportés. Les clients le récupèrent au démarrage pour se configurer, ce qui évite tout codage en dur et permet de prendre en compte automatiquement les changements du fournisseur.

Le flux d’autorisation avec PKCE

Le flux recommandé permet de garder les identifiants hors du navigateur. Le navigateur ne manipule jamais qu’un code à courte durée de vie.

1. Le client génère un code_verifier aléatoire, le hache pour obtenir un code_challenge, et redirige le navigateur vers le fournisseur avec scope=openid.
2. L’utilisateur s’authentifie auprès du fournisseur — le seul endroit où un mot de passe ou un second facteur est saisi.
3. Le fournisseur redirige l’utilisateur en retour avec un code d’autorisation.
4. Le backend échange le code, ainsi que le vérificateur, contre un jeton d’identité (ID token) et un jeton d’accès (access token).
5. Le client valide le jeton d’identité et crée une session.

PKCE (Proof Key for Code Exchange) lie le code au client qui l’a demandé. Un code intercepté pendant le transit est inutile sans le vérificateur. Envoyez toujours state pour prévenir les attaques CSRF et nonce pour lier le jeton d’identité à la requête.

Scopes et claims

Les scopes déterminent les claims que vous pouvez recevoir.

• openid — requis ; sans cela, la requête est du OAuth classique, et non du OIDC.
• profile — nom, photo et autres champs du profil.
• email — l’e-mail de l’utilisateur et son statut de vérification.
• offline_access — demande un refresh token pour que l’application puisse agir ultérieurement.

Demandez le strict minimum. Chaque scope supplémentaire représente davantage de données à protéger et, pour certains fournisseurs, une friction accrue lors du consentement de l’utilisateur.

Le point de terminaison userinfo

Le jeton ID ne contient souvent que les informations de base. Pour obtenir plus de données de profil, appelez le point de terminaison userinfo avec le jeton d’accès :

const userinfo = await client.userinfo(tokenSet.access_token);
// { sub, name, email, email_verified, picture, ... }

Considérez le sub provenant de userinfo comme faisant foi et assurez-vous qu’il correspond au sub contenu dans le jeton ID. Ne faites jamais confiance à un e-mail comme identifiant stable — les utilisateurs peuvent les modifier.

Valider le jeton ID

La validation est l’étape qui rend l’ensemble du processus sécurisé, et c’est celle qui est le plus souvent mal réalisée. Décoder le payload n’est pas une vérification ; n’importe qui peut créer un jeton avec n’importe quelles claims.

Avant de faire confiance à une claim :

1. Signature — vérifiez-la avec la clé publique du fournisseur via l’endpoint JWKS, en utilisant un algorithme autorisé.
2. Issuer — iss doit correspondre au fournisseur attendu.
3. Audience — aud doit être votre client id.
4. Expiry — exp doit être une date future, en tenant compte d’un léger décalage d’horloge (clock skew).
5. Nonce — doit correspondre à la valeur que vous avez envoyée pour cette connexion.

Utilisez une bibliothèque maintenue telle que openid-client et laissez-la gérer ces cinq points. Ne développez pas votre propre parsing de JWT pour l’authentification.

Sessions après la connexion

OIDC effectue l’authentification une seule fois, lors de la connexion. Il ne gère pas la session de votre application. Après avoir validé l’ID token, créez votre propre session — via un cookie ou un token — basée sur sub.

Gardez bien à l’esprit ces trois distinctions :

• L’ID token est destiné à votre client et prouve l’identité.
• L’access token sert à appeler des API.
• Votre session est le mécanisme qui permet à votre application de se souvenir de l’utilisateur entre chaque requête.

Confondre ces éléments peut conduire à exposer des tokens du fournisseur dans le navigateur ou à utiliser un ID token comme identifiant d’API, ce qui constitue une erreur de sécurité.

Déconnexion

La déconnexion locale prime : videz votre session afin que l’utilisateur soit déconnecté de votre application. Cela reste toujours sous votre contrôle et est systématiquement fiable.

La déconnexion fédérée est effectuée au mieux (« best-effort »). Vous pouvez rediriger l’utilisateur vers l’endpoint de fin de session du fournisseur avec un id_token_hint, mais tous les fournisseurs ne le respectent pas et la redirection peut échouer. Concevez votre application de manière à ce que le nettoyage de votre propre session soit suffisant, et ne comptez jamais sur le fournisseur pour déconnecter l’utilisateur.

Quand utiliser OIDC

OIDC est le choix approprié lorsque :

• Vous souhaitez éviter totalement de stocker des mots de passe.
• Vous avez besoin d’un SSO d’entreprise ou de boutons “Se connecter avec…”.
• Votre application fait partie d’un ensemble d’applications devant partager une session de connexion.
• Vous voulez que le MFA et la récupération de compte soient gérés par un spécialiste.

C’est une solution plus lourde qu’un simple formulaire de mot de passe. Pour un petit outil interne avec seulement quelques utilisateurs, l’Authentification par Session et le Hachage de Mot de Passe peuvent être plus simples et tout à fait suffisants.

Bonnes pratiques

• Utilisez toujours le flux d’autorisation (authorization code flow) avec PKCE.
• Envoyez et vérifiez à la fois state et nonce.
• Validez complètement le jeton ID (ID token) : signature, émetteur (issuer), audience et expiration.
• Utilisez la découverte (discovery) plutôt que des points de terminaison (endpoints) codés en dur.
• Demandez le minimum de scopes nécessaires.
• Gardez votre session séparée des jetons du fournisseur.
• Stockez les secrets clients sur le backend, jamais dans le navigateur.

Erreurs courantes

• Confondre OAuth avec l’authentification et tenter d’extraire l’identité à partir d’un access token.
• Décoder l’ID token sans en vérifier la signature.
• Oublier les vérifications aud ou iss, ce qui permet l’acceptation d’un token provenant d’une autre application.
• Utiliser le flux implicite (implicit flow) et exposer ainsi les tokens dans l’URL.
• Utiliser l’adresse e-mail comme clé primaire de l’utilisateur.
• Envoyer les tokens du fournisseur à vos propres API comme s’il s’agissait d’identifiants de session.
• Oublier que la déconnexion doit d’abord supprimer votre session.

Et après ?

Si vous ne l’avez pas encore fait, commencez par OAuth 2.0 pour comprendre le protocole d’autorisation que OIDC étend, ainsi que le guide sur les JWT pour le format des jetons. Une fois la connexion réussie, le guide sur la Session Auth vous explique comment maintenir l’utilisateur connecté, et la section RBAC & Permissions détaille les actions qu’il est autorisé à effectuer.