OpenID Connect (OIDC)

OpenID Connect est une fine couche d’identité construite au-dessus d’OAuth 2.0. OAuth répond à la question que peut faire cette application ; OIDC répond à la question qui est l’utilisateur.

• Il normalise la manière dont les clients authentifient les utilisateurs et reçoivent des revendications d’identité vérifiées.
• Il introduit le jeton ID comme assertion d’authentification signée cryptographiquement.

Avant OIDC, les développeurs utilisaient à tort les jetons d’accès OAuth pour la connexion, ce qui entraînait des failles de type mandataire confus et des problèmes d’usurpation d’identité.

L’élément caractéristique d’OIDC est le jeton ID, un JWT signé qui décrit l’événement d’authentification.

• Il contient des revendications sur l’identité de la personne connectée et sur le moment de sa connexion.
• Il est destiné au client, qui doit le traiter, et non au serveur de ressources.

N’envoyez jamais un jeton ID à une API comme identifiant d’accès et n’en acceptez jamais un sans valider sa signature et ses revendications.

Valider un jeton ID signifie vérifier des revendications précises, et pas seulement la signature.

• L’émetteur iss doit correspondre à l’IdP attendu.
• L’audience aud doit contenir votre client_id.
• Le jeton exp / iat doit ne pas être expiré et avoir été émis récemment.
• sub est l’identifiant stable et unique de l’utilisateur.
• nonce doit correspondre à la valeur envoyée par votre client.

OIDC reprend le flux de code d’autorisation, mais ajoute la portée openid et un nonce.

• Le client demande la portée openid (ainsi que, facultativement, profile et email).
• Le point de terminaison des jetons renvoie un jeton ID en même temps que le jeton d’accès.
• Le nonce lie le jeton ID à la requête d’origine, ce qui empêche le rejeu.

Les fournisseurs OIDC publient leurs clés de signature sur un point de terminaison JWKS, accessible via le document de configuration bien connu.

• Récupérez les clés depuis jwks_uri et faites correspondre l’en-tête kid du jeton.
• Vérifiez la signature avec l’algorithme asymétrique indiqué (RS256, ES256).

Rejetez l’algorithme none et ne faites jamais confiance à une valeur d’algorithme fournie uniquement par le jeton.

Le nonce joue pour les jetons ID le même rôle que state pour la redirection : c’est une valeur à usage unique qui lie la réponse à la requête.

• Le client génère un nonce aléatoire et le stocke dans la session.
• L’IdP le répercute dans le jeton ID.
• À sa réception, le client vérifie que le nonce correspond et n’a pas déjà été utilisé.

Cela bloque le rejeu d’un jeton et l’injection d’un jeton émis pour une autre session.

Pour obtenir des données de profil supplémentaires au-delà du jeton ID, OIDC définit le point de terminaison UserInfo.

• Le client l’appelle avec le jeton d’accès, et non avec le jeton ID.
• Il renvoie des revendications telles que le nom, l’adresse e-mail et la photo du sujet authentifié.

Faites toujours correspondre le sub renvoyé au sub du jeton ID afin d’empêcher la substitution de revendications.

OIDC normalise la découverte afin que les clients puissent configurer automatiquement les points de terminaison et les fonctionnalités prises en charge.

• Le document /.well-known/openid-configuration répertorie les points de terminaison, les portées prises en charge et les algorithmes.
• Épinglez ou validez l’émetteur ; ne suivez pas aveuglément la découverte depuis un hôte contrôlé par un attaquant.

La découverte simplifie l’intégration, mais l’émetteur reste une ancre de confiance que vous devez vérifier.

La fin des sessions entre applications fédérées est gérée par les spécifications de déconnexion OIDC.

• La déconnexion par canal frontal utilise les redirections du navigateur et des cadres intégrés pour déconnecter chaque partie de confiance.
• La déconnexion par canal dorsal envoie des jetons de déconnexion de serveur à serveur ; elle est plus fiable, mais nécessite des points de terminaison.

Sans déconnexion coordonnée, un utilisateur peut se déconnecter d’une application tout en restant connecté aux autres, ce qui constitue un véritable risque pour la gestion des sessions.

Les erreurs liées à l’identité proviennent souvent de l’omission d’étapes de validation.

• Accepter des jetons sans vérifier aud (jeton destiné à un autre client).
• Ignorer iss, ce qui permet l’usurpation d’un IdP.
• Ne pas valider la signature ou accepter alg: none.
• Confondre les jetons ID et les jetons d’accès.
• Omettre la vérification du nonce, ce qui permet le rejeu.

Si votre objectif est la connexion, utilisez OIDC, et non OAuth seul.

• Les jetons d’accès OAuth sont opaques pour le client et ne prouvent rien concernant l’identité.
• Un jeton d’accès peut être valide pour un autre utilisateur ou une autre application, ce qui permet l’usurpation d’identité s’il est utilisé pour la connexion.
• Les jetons ID OIDC sont explicitement des assertions d’identité liées à une audience.

Cette distinction empêche la faille classique d’authentification du mandataire confus.

Choisissez l’étape de validation la plus importante pour une partie de confiance qui traite un jeton ID.

Points essentiels :

• OIDC ajoute une couche d’identité à OAuth 2.0 ; le jeton ID est un JWT signé qui atteste l’authentification.
• Validez toujours iss, aud, exp, signature (via JWKS) et nonce.
• Les jetons ID sont destinés au client ; les jetons d’accès sont destinés aux API : n’intervertissez jamais leurs rôles.
• Utilisez nonce contre le rejeu et state contre le CSRF.
• Utilisez OIDC, et non OAuth seul, lorsque vous devez authentifier des utilisateurs.