08. ID token et access token

Comprendre le mécanisme

OpenID Connect ajoute une couche d’identité à OAuth. L’ID token exprime des informations destinées au client selon le flux OIDC, avec des règles de validation propres. Un access token sert à présenter une autorisation au serveur de ressources selon son profil ; il peut être opaque ou structuré. La présence d’un utilisateur dans les deux ne les rend pas interchangeables.

Raisonner et vérifier

Attribuez à chaque composant le jeton qu’il doit consommer. Le client valide son contexte d’authentification, notamment nonce lorsqu’il est requis par le flux, tandis que l’API valide son audience et ses règles d’accès. Un token ne remplace pas les contrôles du protocole de redirection. Documentez les flux et bibliothèques choisis plutôt que reconstituer OAuth à partir de trois segments.

Destinataire OIDC

Un ID token vise le client OIDC selon son profil. Les consommateurs et profils doivent être distingués. Un ID token informe le client OIDC d’un résultat d’authentification selon son flux. Une API de ressources ne doit pas l’accepter comme jeton d’accès simplement parce que sa signature est valide.

Token opaque

Un access token peut être opaque. Le protocole ne fixe pas universellement cette représentation. Le rôle access token n’impose pas une représentation JWT. Le serveur de ressources applique le mécanisme prévu, par exemple introspection ou validation locale, sans tenter de décoder arbitrairement toute chaîne.

Audience API

Une API doit vérifier sa propre audience attendue. La destination reste une exigence du profil. Votre API vérifie sa propre audience dans le profil approprié. Un token destiné à web-client ne devient pas acceptable pour reservation-api parce que les deux appartiennent à la même organisation.

Nonce

nonce peut lier le contexte selon le flux OIDC. Les contrôles de contexte et de preuve sont complémentaires. Dans les flux où il est utilisé, nonce relie la réponse au contexte initié par le client. Il complète les autres validations OIDC et ne remplace jamais à lui seul signature ou contrôle d’émetteur.

Flux choisi

Le client doit suivre les règles du flux choisi. La sérialisation ne définit pas tout le protocole. Code, échanges serveur et stockage de contexte ont des exigences précises. Utilisez une bibliothèque de protocole et testez les chemins d’erreur, plutôt que reconstruire un login en lisant seulement les claims.

Redirection

Les règles de redirection restent nécessaires. Le protocole de retour a ses propres contraintes. Les destinations de retour doivent être enregistrées et comparées selon les règles applicables. Une redirection trop libre peut détourner un code ou un token malgré une authentification utilisateur correcte.

Sujet et droit

Le sujet d’un ID token ne prouve pas toute permission d’API. L’identité ne détermine pas seule les droits. Le sujet authentifié peut être reconnu par le client sans posséder de permission sur une facture de l’API. Les droits de ressource doivent être évalués dans leur contexte métier.

Substitution signée

Une substitution de profil doit être testée avec une signature valide. Un cas correctement signé isole le contrôle de profil. Testez un ID token correctement signé là où un access token est exigé. Une signature volontairement invalide ne démontre pas le rejet du mauvais profil puisqu’elle échoue plus tôt.

Bibliothèque adaptée

Une bibliothèque adaptée aide à appliquer le protocole. Il manque les échanges et vérifications du flux. Une bibliothèque JWT générale ne fournit pas nécessairement tout le flux OIDC. Vérifiez gestion d’état, nonce, découverte et erreurs requises par le rôle que votre composant assume.

Claims ressemblants

L’ID token et l’access token peuvent partager des claims sans être interchangeables. La signification dépend du rôle et du destinataire. iss, sub et exp peuvent apparaître dans plusieurs tokens. Leur ressemblance ne rend pas les profils interchangeables ; type, audience et règles du protocole déterminent l’usage admissible.

Atelier guidé : lire, expliquer et vérifier le code

{
  "consumer": "reservation-api",
  "receivedProfile": "ID token",
  "aud": "web-client",
  "signature": "valid"
}

Le token reçu est explicitement un ID token pour web-client et le consommateur est reservation-api. Sa signature valide ne corrige ni le rôle ni l’audience. Écrivez un test de substitution avec une preuve correcte et confirmez le refus avant tout accès aux données de réservation.

La preuve ne remplace pas le contrat de destination. La validation doit refuser la substitution de rôle et d’audience. Les deux usages ne sont pas interchangeables. Les noms désignent des consommateurs différents.

Travail pratique : Préparez un ID token et un access token de laboratoire avec audiences différentes. Envoyez chacun aux deux composants.

Critères de correction : Seules les combinaisons du contrat doivent réussir. Vérifiez que l’API refuse un token d’identité même si sa signature est correcte et son utilisateur connu.