Claims Standards OpenID Connect

OpenID Connect

OpenID Connect (OIDC) est un protocole d’authentification construit au-dessus d’OAuth 2.0, conçu pour fournir des capacités d’authentification et d’autorisation des utilisateurs pour les applications. L’un des composants clés d’OIDC est le concept de jetons (tokens). Les jetons transportent des informations sur le contexte d’authentification et d’autorisation et sont utilisés pour effectuer des requêtes sécurisées et autorisées. Dans cet article de blog, nous explorerons les différents types de claims (revendications) présents dans les jetons OIDC et comprendrons leur importance dans le processus d’authentification.

Claims de jeton d’accès (Access Token Claims)

Les jetons d’accès dans OIDC sont utilisés pour autoriser l’accès à des ressources protégées au nom d’un utilisateur. Ils contiennent un ensemble de claims qui transmettent des informations sur l’utilisateur. Comme OpenID Connect est basé sur OAuth 2.0, vous devriez consulter la liste dans notre autre article traitant des claims de jeton d’accès OAuth 2.

Claims de jeton d’ID (ID Token Claims)

Le jeton d’ID (ID token) est un jeton JSON Web Token (JWT) qui contient des claims sur l’événement d’authentification et sur l’utilisateur. Il est utilisé pour authentifier l’utilisateur et fournir des informations sur son identité. Le jeton d’ID est généralement consommé par l’application cliente pour vérifier l’identité de l’utilisateur et obtenir des informations le concernant. Voici quelques-uns des claims standards présents dans le jeton d’ID :

  • iss : Le claim issuer représente l’émetteur du jeton.
  • sub : Le claim subject représente le sujet du jeton, qui est généralement l’identifiant de l’utilisateur.
  • aud : Le claim audience représente le public auquel le jeton est destiné.
  • exp : Le claim expiration time indique le moment où le jeton expire.
  • iat : Le claim issued at représente le moment où le jeton a été émis.
  • auth_time : Le claim authentication time indique le moment où l’utilisateur s’est authentifié.
  • nonce : Le claim nonce est utilisé pour empêcher les attaques par rejeu.
  • acr : Le claim authentication context class reference représente la référence de classe de contexte d’authentification.
  • amr : Le claim authentication methods references contient les méthodes d’authentification utilisées.
  • azp : Le claim authorized party représente la partie autorisée pour laquelle le jeton est destiné.

Focus sur le claim amr

Le claim amr est utilisé pour transmettre des informations sur les méthodes d’authentification utilisées pour authentifier l’utilisateur. Il fournit des détails sur les méthodes et mécanismes d’authentification utilisés lors du processus d’authentification. Le claim amr peut contenir une ou plusieurs valeurs représentant les méthodes d’authentification utilisées, telles qu’un mot de passe, un OTP ou une authentification biométrique.

Exemple d’une charge utile (payload) de jeton d’ID contenant le claim amr :

{
"iss": "https://auth.example.com",
"sub": "1234567890",
"aud": "https://api.example.com",
"exp": 1635200000,
"iat": 1635196400,
"amr": ["pwd", "otp"]
}

Les différentes valeurs disponibles sont définies dans la spécification Authentication Method Reference Values RFC 8176.

Focus sur le claim acr

Le claim acr est utilisé pour transmettre des informations sur la référence de classe de contexte d’authentification. Il représente le niveau d’assurance ou de confiance dans le processus d’authentification. Le claim acr fournit des détails sur le contexte d’authentification et la robustesse des mécanismes d’authentification utilisés lors du processus d’authentification.

Exemple d’une charge utile (payload) de jeton d’ID contenant le claim acr :

{
"iss": "https://auth.example.com",
"sub": "1234567890",
"aud": "https://api.example.com",
"exp": 1635200000,
"iat": 1635196400,
"acr": "http://schemas.openid.net/pape/policies/2007/06/multi-factor"
}

Dans cet exemple, le claim acr indique que le processus d’authentification a nécessité une authentification multifacteur. La valeur du claim acr peut varier en fonction du contexte d’authentification et du niveau d’assurance fourni par les mécanismes d’authentification.

Certaines des valeurs courantes pour le claim acr incluent :

  • http://schemas.openid.net/pape/policies/2007/06/multi-factor : Indique une authentification multifacteur.
  • http://schemas.openid.net/pape/policies/2007/06/phishing-resistant : Indique une authentification résistante au hameçonnage.
  • http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical : Indique une authentification multifacteur physique.

Focus sur le claim azp

Le claim azp est utilisé pour transmettre des informations sur la partie autorisée pour laquelle le jeton est destiné. Il représente l’identifiant client (client ID) de la partie autorisée qui est autorisée à utiliser le jeton. Le claim azp est généralement utilisé dans les scénarios où le jeton d’ID est destiné à une application cliente spécifique.

Exemple d’une charge utile (payload) de jeton d’ID contenant le claim azp :

{
"iss": "https://auth.example.com",
"sub": "1234567890",
"aud": "https://api.example.com",
"exp": 1635200000,
"iat": 1635196400,
"azp": "client_id"
}

Dans cet exemple, the claim azp indique que le jeton est destiné à l’application cliente avec l’identifiant client client_id. Le claim azp permet de s’assurer que le jeton n’est utilisé que par la partie autorisée à laquelle il est destiné.

Claims d’identité standards

En plus des claims OAuth 2.0, il existe des claims d’identité standards qui fournissent des informations spécifiques sur le profil et les attributs de l’utilisateur. Ces claims offrent un moyen standardisé de transmettre des données d’identité essentielles. Explorons certains des claims d’identité standards les plus couramment utilisés :

  • name : Le claim name représente le nom complet de l’utilisateur.
  • given_name : Ce claim contient le prénom de l’utilisateur.
  • family_name : Le claim family name représente le nom de famille de l’utilisateur.
  • middle_name : Le claim middle name contient le deuxième prénom de l’utilisateur, le cas échéant.
  • nickname : Le claim nickname contient un surnom ou un pseudonyme utilisé par l’utilisateur.
  • preferred_username : Ce claim représente le nom d’utilisateur ou l’identifiant préféré de l’utilisateur.
  • profile : Le claim profile pointe vers une URL qui fournit des informations de profil supplémentaires sur l’utilisateur.
  • picture : Le claim picture fournit une URL vers la photo de profil ou l’avatar de l’utilisateur.
  • website : Ce claim contient l’URL du site web ou de la page d’accueil de l’utilisateur.
  • email : Le claim email représente l’adresse e-mail de l’utilisateur.
  • email_verified : Le claim email verified indique si l’adresse e-mail de l’utilisateur a été vérifiée.
  • gender : Ce claim spécifie le genre ou le sexe de l’utilisateur.
  • birthdate : Le claim birthdate indique la date de naissance de l’utilisateur.
  • zoneinfo : Ce claim représente le fuseau horaire ou la région géographique de l’utilisateur.
  • locale : Le claim locale indique la langue et les préférences culturelles de l’utilisateur.
  • phone_number : Le claim phone number contient le numéro de téléphone de l’utilisateur.
  • phone_number_verified : Le claim phone number verified indique si le numéro de téléphone de l’utilisateur a été vérifié.
  • address : Ce claim contient l’adresse postale de l’utilisateur ou des parties de celle-ci.
  • updated_at : Le claim updated at représente le moment où les informations de l’utilisateur ont été mises à jour pour la dernière fois.

Une liste exhaustive de ces claims est disponible dans les spécifications d’OpenID Connect. Si vous souhaitez en savoir plus sur les claims existants pour les JWT de manière plus générale, vous pouvez consulter le registre des claims JWT de l’IANA.

Ces claims d’identité standards offrent un moyen standardisé de transmettre des attributs utilisateur importants dans les jetons OpenID Connect. Cependant, il est important de noter que la disponibilité et l’inclusion de ces claims peuvent varier en fonction du fournisseur d’identité, ainsi que du consentement et des paramètres de confidentialité de l’utilisateur. De plus, des claims personnalisés peuvent être définis pour inclure des informations d’identité spécifiques au domaine selon les besoins.