Vue d’ensemble des jetons et des revendications

  • Article

Un fournisseur d’identité centralisé est particulièrement utile pour les applications ayant des utilisateurs du monde entier qui ne se connectent pas nécessairement à partir du réseau de l’entreprise. La plateforme d’identités Microsoft authentifie les utilisateurs et fournit des jetons de sécurité, tels que des jetons d’accès, des jetons d’actualisation et des jetons d’ID. Les jetons de sécurité permettent à une application cliente d’accéder à des ressources protégées sur un serveur de ressources.

  • Jeton d’accès – Un jeton d’accès est un jeton de sécurité émis par un serveur d’autorisation dans le cadre d’un flux OAuth 2.0. Il contient des informations sur l’utilisateur et la ressource à laquelle le jeton est destiné. Les informations peuvent être utilisées pour accéder à des API web et à d’autres ressources protégées. Les ressources valident les jetons d’accès pour accorder l’accès à une application cliente. Pour plus d’informations, consultez Jetons d’accès dans la plateforme d’identités Microsoft.
  • Jeton d’actualisation – Les jetons d’accès n’étant valides que pendant une courte période, les serveurs d’autorisation émettent parfois un jeton d’actualisation en même temps que le jeton d’accès. L’application cliente peut alors échanger ce jeton d’actualisation contre un nouveau jeton d’accès si nécessaire. Pour plus d’informations, consultez Jetons d’actualisation dans la plateforme d’identités Microsoft.
  • Jeton d’ID : les jetons d’ID sont envoyés à l’application cliente dans le cadre d’un flux OpenID Connect. Ils peuvent être envoyés en même temps qu’un jeton d’accès ou à la place de celui-ci. Les jetons d’ID sont utilisés par le client pour authentifier l’utilisateur. Pour en savoir plus sur la façon dont la plateforme d’identités Microsoft émet des jetons d’ID, consultez Jetons d’ID dans la plateforme d’identités Microsoft.

De nombreuses applications d’entreprise utilisent SAML pour authentifier les utilisateurs. Pour plus d’informations sur les assertions SAML, consultez Informations de référence sur les jetons SAML.

Valider les jetons

La validation du jeton revient à l’application pour laquelle le jeton a été généré, à l’application web qui a connecté l’utilisateur ou à l’API web appelée. Le serveur d’autorisation signe le jeton avec une clé privée. Le serveur d’autorisation publie la clé publique correspondante. Pour valider un jeton, l’application vérifie la signature à l’aide de la clé publique du serveur d’autorisation et confirme ainsi que la signature a été créée au moyen de la clé privée. Pour plus d’informations, consultez l’article Sécuriser les applications et les APIs en validant les revendications.

Nous vous recommandons d’utiliser lesbibliothèques de Microsoft Authenticator prises en charge (MSAL) autant que possible. Cela implémente l’acquisition, l’actualisation et la validation des jetons pour vous. Il met également en œuvre une découverte conforme aux normes des paramètres et des clés du locataire à l’aide du document de découverte OpenID bien connu du locataire. MSAL prend en charge de nombreuses architectures et plateformes d’application différentes, notamment .NET, JavaScript, Java, Python, Android et iOS.

Les jetons étant valides pour une durée limitée, le serveur d’autorisation fournit régulièrement une paire de jetons. Un jeton d’accès est fourni, lequel permet d’accéder à l’application ou à la ressource protégée. Un jeton d’actualisation est fourni, lequel permet d’actualiser le jeton d’accès lorsque celui-ci arrive à expiration.

Les jetons d’accès sont passés à une API web en tant que jeton du porteur dans l’en-tête Authorization. Une application peut fournir un jeton d’actualisation au serveur d’autorisation. Si l’accès utilisateur à l’application n’a pas été révoqué, il reçoit un nouveau jeton d’accès et un nouveau jeton d’actualisation. Lorsque le serveur d’autorisation reçoit le jeton d’actualisation, il n’émet un autre jeton d’accès que si l’utilisateur est toujours autorisé.

Jetons JSON Web Token et revendications

La plateforme d’identités Microsoft implémente des jetons de sécurité comme des jetons JSON Web Token (JWT) qui contiennent des revendications. Étant donné que les jetons JWT sont utilisés comme jetons de sécurité, cette forme d’authentification est parfois appelée Authentification JWT.

Une revendication fournit des assertions sur une entité (telle qu’une application cliente ou un propriétaire de ressources) à une autre entité, telle qu’un serveur de ressources. Une revendication peut également être appelée revendication JWT ou revendication JSON Web Token.

Les revendications sont des paires de noms ou de valeurs qui relaient des faits sur le sujet du jeton. Par exemple, une revendication peut contenir des faits sur le principal de sécurité que le serveur d’autorisation a authentifié. Les revendications présentes dans un jeton spécifique dépendent de plusieurs variables, comme le type de jeton, le type d’informations d’identification utilisées pour authentifier le sujet et la configuration de l’application.

Les applications peuvent utiliser des revendications pour les différentes tâches suivantes :

  • Valider le jeton
  • Identifier le locataire du sujet du jeton
  • Afficher les informations utilisateur
  • Déterminer l’autorisation du sujet

Une revendication se compose de paires clé-valeur qui fournissent les types d’informations suivants :

  • Serveur de jetons de sécurité qui a généré le jeton
  • date à laquelle le jeton a été généré ;
  • Sujet (comme l’utilisateur, mais pas les démons)
  • audience, qui est l’application pour laquelle le jeton a été généré ;
  • Application (le client) qui a demandé le jeton

Points de terminaison et émetteurs de jetons

Microsoft Entra ID prend en charge deux configurations de locataire : une configuration de personnel destinée à un usage interne et qui gère les employés et les invités professionnels, et une configuration client optimisée pour isoler les consommateurs et les partenaires dans un annuaire externe restreint. Bien que le service d’identité sous-jacent soit identique pour les deux configurations de tenant, les domaines de connexion et l’autorité d’émission de jetons pour les tenants externes sont différents. Cela permet aux applications de séparer les workflows de main-d'œuvre et d'identification externe si nécessaire.

Les locataires de ressources Microsoft Entra s’authentifient auprès de login.microsoftonline.com avec des jetons émis par sts.windows.net. Les jetons de locataire du personnel sont généralement échangeables entre les locataires et les applications multi-locataires, à condition que les relations de confiance sous-jacentes permettent cette interopérabilité. Les tenants externes Microsoft Entra utilisent des points de terminaison affectés aux tenants du formulaire {tenantname}.ciamlogin.com. Les applications inscrites auprès des tenants externes doivent avoir conscience de cette séparation pour recevoir et valider correctement les jetons.

Chaque locataire Microsoft Entra publie des métadonnées connues et conformes. Ce document contient des informations sur le nom de l'émetteur, les points de terminaison d'authentification et d'autorisation, les étendues et les revendications prises en charge. Pour les tenants externes, le document est disponible publiquement sur : https://{tenantname}.ciamlogin.com/{tenantid}/v2.0/.well-known/openid-configuration. Ce point de terminaison retourne une valeur d’émetteur https://{tenantid}.ciamlogin.com/{tenantid}/v2.0.

Flux d’autorisation et codes d’authentification

Selon la façon dont votre client est créé, il peut utiliser un ou plusieurs des flux d’authentification pris en charge par la plateforme d’identités Microsoft. Les flux pris en charge peuvent produire divers jetons et codes d’autorisation et exiger des jetons différents pour permettre leur fonctionnement. Le tableau suivant offre une vue d'ensemble.

Flux Nécessite Jeton d’ID Access token (Jeton d’accès) Jeton d’actualisation Code d’autorisation.
Flux du code d’autorisation x x x x
Flux implicite x x
Circuit OIDC hybride x x
Échange de jetons d’actualisation Jeton d’actualisation x x x
Flux On-Behalf-Of Access token (Jeton d’accès) x x x
Informations d’identification du client x (application uniquement)

Les jetons émis en utilisant le flux implicite sont limités en longueur, car ils sont renvoyés au navigateur en utilisant l’URL, où response_mode a la valeur query ou fragment. Certains navigateurs limitent la taille de l’URL qui peut être placée dans la barre d’adresse et refusent les URL trop longues. Par conséquent, ces jetons n’ont pas de revendications groups ou wids.

Voir aussi

Étapes suivantes