Accueil > OpenID Connect OAuth Server par DnC > Développer > OpenID Connect : le jeton d’identité ( ID Token ) JWT

OpenID Connect : le jeton d’identité ( ID Token ) JWT

Dans le cadre d’OpenID Connect, le jeton d’identité (ID_Token) suit la définition générale du jeton JSON Web Token (JWT). Cependant, les déclarations de la charge utile définies pour OpenID Connect diffèrent sur certains points et quelques déclarations spécifiques complètent le format.

La spécification du jeton d’identité (ID_Token) pour OpenID Connect est donnée ici : OpenID Connect Core 1.0 incorporating errata set 1 :

2. Jeton d’identité

L’extension principale qu’OpenID Connect fait à OAuth 2.0 pour permettre aux utilisateurs finaux d’être authentifiés est la structure de données du jeton d’identité. Le jeton d’identité est un jeton de sécurité qui contient des déclarations concernant l’authentification d’un utilisateur final par un serveur d’autorisation lors de l’utilisation d’un client, et éventuellement d’autres déclarations demandées. Le jeton ID est représenté comme un jeton Web JSON (JWT).

Les déclarations suivantes sont utilisées dans le jeton ID pour tous les flux OAuth 2.0 utilisés par OpenID Connect :

iss
OBLIGATOIRE. Identifiant de l’émetteur pour l’émetteur de la réponse. La valeur iss est une URL sensible à la casse utilisant le schéma https qui contient des composants de schéma, d’hôte et, éventuellement, de numéro de port et de chemin d’accès et aucun composant de requête ou de fragment.
sub
OBLIGATOIRE. Identifiant du sujet. Un identifiant localement unique et jamais réaffecté au sein de l’émetteur pour l’utilisateur final, qui est destiné à être consommé par le client, par exemple, 24400320 ou AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. Il NE DOIT PAS dépasser 255 caractères ASCII. La sous-valeur est une chaîne sensible à la casse.
aud
OBLIGATOIRE. Public (s) auquel ce jeton d’identité est destiné. Il DOIT contenir le client_id OAuth 2.0 de la partie utilisatrice comme valeur d’audience. Il PEUT également contenir des identifiants pour d’autres publics. Dans le cas général, la valeur aud est un tableau de chaînes sensibles à la casse. Dans le cas spécial courant où il n’y a qu’une audience, la valeur aud PEUT être une chaîne unique sensible à la casse.
exp
OBLIGATOIRE. Heure d’expiration à partir de laquelle le jeton d’identité NE DOIT PAS être accepté pour le traitement. Le traitement de ce paramètre nécessite que la date / heure actuelle DOIT être antérieure à la date / heure d’expiration répertoriée dans la valeur. Les implémenteurs PEUVENT prévoir une petite marge de manœuvre, généralement pas plus de quelques minutes, pour tenir compte du décalage d’horloge. Sa valeur est un nombre JSON représentant le nombre de secondes à partir de 1970-01-01T0 : 0 : 0Z mesuré en UTC jusqu’à la date / heure. Voir RFC 3339 [RFC3339] pour plus de détails concernant la date / heure en général et UTC en particulier.
iat
OBLIGATOIRE. Heure à laquelle le JWT a été émis. Sa valeur est un nombre JSON représentant le nombre de secondes à partir de 1970-01-01T0 : 0 : 0Z mesuré en UTC jusqu’à la date / heure.
auth_time
Heure à laquelle l’authentification de l’utilisateur final s’est produite. Sa valeur est un nombre JSON représentant le nombre de secondes à partir de 1970-01-01T0 : 0 : 0Z mesuré en UTC jusqu’à la date / heure. Lorsqu’une demande max_age est effectuée ou lorsque auth_time est demandé en tant que revendication essentielle, cette revendication est OBLIGATOIRE ; sinon, son inclusion est FACULTATIVE. (La revendication auth_time correspond sémantiquement au paramètre de réponse auth_time OpenID 2.0 PAPE [OpenID.PAPE].)
nonce
Valeur de chaîne utilisée pour associer une session client à un jeton d’identité et pour atténuer les attaques de relecture. La valeur est transmise sans modification de la demande d’authentification au jeton ID. S’il est présent dans le jeton d’identité, les clients DOIVENT vérifier que la valeur de réclamation nonce est égale à la valeur du paramètre nonce envoyé dans la demande d’authentification. S’ils sont présents dans la demande d’authentification, les serveurs d’autorisation DOIVENT inclure une réclamation nonce dans le jeton d’identité, la valeur de réclamation étant la valeur nonce envoyée dans la demande d’authentification. Les serveurs d’autorisation NE DEVRAIENT effectuer aucun autre traitement sur les valeurs nonce utilisées. La valeur nonce est une chaîne sensible à la casse.
acr
FACULTATIF. Référence de classe de contexte d’authentification. Chaîne spécifiant une valeur de référence de classe de contexte d’authentification qui identifie la classe de contexte d’authentification satisfaite par l’authentification. La valeur "0" indique que l’authentification de l’utilisateur final ne répond pas aux exigences du niveau 1. ISO / IEC 29115 [ISO29115]. L’authentification à l’aide d’un cookie de navigateur de longue durée, par exemple, est un exemple où l’utilisation du "niveau 0" est approprié. Les authentifications de niveau 0 NE DEVRAIENT PAS être utilisées pour autoriser l’accès à toute ressource de quelque valeur monétaire que ce soit. (Cela correspond au PAPIER OpenID 2.0 [OpenID.PAPE] nist_auth_level 0.) Un URI absolu ou un nom enregistré RFC 6711 [RFC6711] DEVRAIT être utilisé comme valeur acr ; les noms enregistrés NE DOIVENT PAS être utilisés avec une signification différente de celle qui est enregistrée. Les parties utilisant cette allégation devront s’entendre sur la signification des valeurs utilisées, qui peuvent être spécifiques au contexte. La valeur acr est une chaîne sensible à la casse.
amr
FACULTATIF. Références aux méthodes d’authentification. Tableau JSON de chaînes qui sont des identifiants pour les méthodes d’authentification utilisées dans l’authentification. Par exemple, des valeurs peuvent indiquer que des méthodes d’authentification par mot de passe et OTP ont été utilisées. La définition de valeurs particulières à utiliser dans la revendication amr dépasse le cadre de cette spécification. Les parties utilisant cette allégation devront s’entendre sur la signification des valeurs utilisées, qui peuvent être spécifiques au contexte. La valeur amr est un tableau de chaînes sensibles à la casse.
azp
FACULTATIF. Partie autorisée - la partie à laquelle le jeton d’identité a été délivré. S’il est présent, il DOIT contenir l’ID client OAuth 2.0 de cette partie. Cette déclaration n’est nécessaire que lorsque le jeton d’identification a une seule valeur d’audience et que cette audience est différente de la partie autorisée. Il PEUT être inclus même lorsque la partie autorisée est la même que le seul public. La valeur azp est une chaîne sensible à la casse contenant une valeur StringOrURI.

Les jetons d’identification PEUVENT contenir d’autres déclarations. Toute déclaration utilisée qui n’est pas comprise DOIT être ignorée. Voir les sections 3.1.3.6, 3.3.2.11, 5.1 et 7.4 pour les déclarations supplémentaires définies par cette spécification.

Les jetons d’identification DOIVENT être signés à l’aide de JWS [JWS] et éventuellement signés puis chiffrés à l’aide de JWS [JWS] et JWE [JWE] respectivement, fournissant ainsi l’authentification, l’intégrité, la non-répudiation et, éventuellement, la confidentialité, conformément à la section 16.14. Si le jeton d’identification est chiffré, il DOIT être signé puis chiffré, le résultat étant un JWT imbriqué, comme défini dans JWT.

Les jetons d’identification NE DOIVENT PAS utiliser ’none’ comme valeur alg, sauf si le type de réponse utilisé ne renvoie aucun jeton d’identification du point de terminaison d’autorisation (comme lors de l’utilisation du flux de code d’autorisation) et si le client a explicitement demandé l’utilisation de ’none’ au moment de l’enregistrement.

Les jetons d’identification NE DEVRAIENT PAS utiliser dans le champ d’entête les paramètres JWS ou JWE x5u, x5c, jku ou jwk. Au lieu de cela, les références aux clés utilisées sont communiquées à l’avance à l’aide des paramètres de découverte et d’enregistrement, conformément à la section 10.

Voici un exemple non normatif de l’ensemble de revendications (l’ensemble de déclarations JWT) dans un jeton d’identification :

{
  "iss": "https://server.example.com",
  "sub": "24400320",
  "aud": "s6BhdRkqt3",
  "nonce": "n-0S6_WzA2Mj",
  "exp": 1311281970,
  "iat": 1311280970,
  "auth_time": 1311280969,
  "acr": "urn:mace:incommon:iap:silver"
 }

Audience

Cette déclaration est interprétée différemment selon les OpenID Connect Provider (OP).

Rappelons que le jeton d’identité (ID Token) est un "jeton au porteur" (Bearer Token).
La plupart des systèmes utilisent donc la déclaration ’audience’ pour définir les applications qui peuvent légitimement présenter le jeton sous la forme :

"https://app-one.com", "https://app-two.com".

Il faut observer que les ressources protégées qui présentent le jeton à l’introspection peuvent également être mentionnées dans la liste des applications autorisées.

On voit que la déclaration audience appartient à ces définitions propres à un domaine particulier, dans lequel les applications et le serveur OpenID Connect Provider (OP) partagent la même interprétation.

C’est bien dans ce cas que se trouve OAuthSD qui est conçu et distribué comme OP privé.