OAuth 2.0 et OpenID Connect (OIDC) sur la plateforme d’identités Microsoft

  • Article

Connaître OAuth ou OpenID Connect (OIDC) au niveau du protocole n’est pas nécessaire pour utiliser la plateforme d’identités Microsoft. Toutefois, vous rencontrerez des termes et concepts du protocole lorsque vous utiliserez la plateforme d’identité pour ajouter l’authentification à vos applications. Lorsque vous travaillez avec le centre d’administration Microsoft Entra, notre documentation et nos bibliothèques d’authentification, le fait de connaître certaines notions de base peut faciliter votre intégration et votre expérience globale.

Rôles dans OAuth 2.0

Quatre parties sont généralement impliquées dans un échange d’authentification et d’autorisation OAuth 2.0 et OpenID Connect. Ces échanges sont souvent appelés flux d’authentification ou flux auth.

Diagramme montrant les rôles OAuth 2.0

  • Serveur d’autorisation : la plateforme d’identités Microsoft est le serveur d’autorisation. Également appelé fournisseur d’identités ou IdP, il gère en toute sécurité les informations de l’utilisateur final, son accès et les relations d’approbation entre les parties dans le flux d’authentification. Le serveur d’autorisation émet les jetons de sécurité utilisés par vos applications et API pour accorder, refuser ou révoquer l’accès aux ressources (autorisation) une fois que l’utilisateur s’est connecté (authentifié).

  • Client : le client dans un échange OAuth est l’application qui demande l’accès à une ressource protégée. Le client peut être une application web exécutée sur un serveur, une application web monopage s’exécutant dans le navigateur web d’un utilisateur ou une API web qui appelle une autre API web. Vous verrez souvent le client appelé application cliente, application ou app.

  • Propriétaire de la ressource : le propriétaire de la ressource dans un flux d’authentification est généralement l’utilisateur de l’application ou l'utilisateur final dans la terminologie OAuth. L’utilisateur final « possède » la ressource protégée (ses données), à laquelle votre application accède en son nom. Les propriétaires des ressources peuvent accorder ou refuser à votre application (le client) l’accès aux ressources dont ils sont propriétaires. Par exemple, votre application peut appeler l’API d’un système externe pour obtenir l’adresse e-mail d’un utilisateur à partir de son profil sur ce système. Ses données de profil sont une ressource que l’utilisateur final possède sur le système externe, et l’utilisateur final peut donner son consentement ou refuser la demande d’accès à ses données à votre application.

  • Serveur de ressources : le serveur de ressources héberge ou donne accès aux données d’un propriétaire de ressources. Le plus souvent, le serveur de ressources est une API web devant un magasin de données. Le serveur de ressources s’appuie sur le serveur d’autorisation pour effectuer l’authentification et utilise les informations des jetons du porteur émis par le serveur d’autorisation pour accorder ou refuser l’accès aux ressources.

Jetons

Les parties d’un flux d’authentification utilisent des jetons du porteur pour assurer, vérifier et authentifier un principal (utilisateur, hôte ou service) et octroyer ou refuser l’accès aux ressources protégées (autorisation). Les jetons du porteur dans la plateforme d’identités Microsoft sont formatés en tant que jetons web JSON (JWT).

Trois types de jetons du porteur sont utilisés par la plateforme d’identités en tant que jetons de sécurité :

  • Jetons d’accès : les jetons d’accès sont émis par le serveur d’autorisation à l’application cliente. Le client transmet les jetons d’accès au serveur de ressources. Les jetons d’accès contiennent les autorisations octroyées par le client au serveur d’autorisation.

  • Jetons d’accès : les jetons d’accès sont émis par le serveur d’autorisation à l’application cliente. Les clients utilisent des jetons d’ID lors de la connexion des utilisateurs et pour obtenir des informations de base à leur sujet.

  • Jetons d’actualisation : le client utilise un jeton d’actualisation, ou RT, pour demander de nouveaux jetons d’accès et d’ID au serveur d’autorisation. Votre code doit traiter les jetons d’actualisation et leur contenu de chaîne comme des données sensibles, car ils sont destinés à être utilisés uniquement par le serveur d’autorisation.

Inscription d'application

Votre application cliente a besoin d’un moyen d’approuver les jetons de sécurité qui lui sont émis par la plateforme d’identités Microsoft. La première étape de l’établissement de l’approbation consiste à inscrire votre application. Lorsque vous inscrivez votre application, la plateforme d’identités lui attribue automatiquement des valeurs, tandis que d’autres sont attribuées en fonction du type de l’application.

Deux des paramètres d’inscription d’application les plus couramment référencés sont :

  • ID d’application (client) : également appelé ID d’application et ID client, cette valeur est attribuée à votre application par la plateforme d’identités. L’ID client identifie de manière unique votre application dans la plateforme d’identité et est inclus dans les jetons de sécurité que la plateforme émet.
  • URI de redirection : le serveur d’autorisation utilise un URI de redirection pour diriger l'agent utilisateur du propriétaire de la ressource (navigateur web, application mobile) vers une autre destination après avoir terminé son interaction. Par exemple, une fois que l’utilisateur final s’est authentifié auprès du serveur d’autorisation. Tous les types de client utilisent des URI de redirection.

L’inscription de votre application contient également des informations sur les points de terminaison d’authentification et d’autorisation que vous allez utiliser dans votre code pour obtenir des jetons d’ID et d’accès.

Points de terminaison

La plateforme d’identités Microsoft offre des services d’authentification et d’autorisation à l’aide d’implémentations conformes aux normes d’OAuth 2.0 et OpenID Connect (OIDC) 1.0. Les serveurs d’autorisation conformes aux normes tels que la plateforme d’identités fournissent un ensemble de points de terminaison HTTP utilisables par les parties dans un flux d’authentification pour exécuter le flux.

Les URI de point de terminaison de votre application sont générés automatiquement lorsque vous inscrivez ou configurez votre application. Les points de terminaison que vous utilisez dans le code de votre application dépendent du type de l’application et des identités (types de comptes) qu’elle doit prendre en charge.

Deux points de terminaison couramment utilisés sont le point de terminaison d’autorisation et le point de terminaison de jeton. Voici des exemples de points de terminaison authorize et token :

# Authorization endpoint - used by client to obtain authorization from the resource owner.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/authorize
# Token endpoint - used by client to exchange an authorization grant or refresh token for an access token.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/token

# NOTE: These are examples. Endpoint URI format may vary based on application type,
#       sign-in audience, and Azure cloud instance (global or national cloud).

#       The {issuer} value in the path of the request can be used to control who can sign into the application. 
#       The allowed values are **common** for both Microsoft accounts and work or school accounts, 
#       **organizations** for work or school accounts only, **consumers** for Microsoft accounts only, 
#       and **tenant identifiers** such as the tenant ID or domain name.

Pour rechercher les points de terminaison d’une application que vous avez inscrite, dans le centre d’administration Microsoft Entra, accédez à :

Applications d'>identité>Enregistrements d'applications><YOUR-APPLICATION>>Points de terminaison

Étapes suivantes

Ensuite, découvrez les flux d’authentification OAuth 2.0 utilisés par chaque type d’application et les bibliothèques que vous pouvez utiliser dans vos applications pour les exécuter :

Nous vous déconseillons vivement de créer votre propre bibliothèque ou vos propres appels HTTP bruts pour exécuter des flux d’authentification. Une bibliothèque d’authentification Microsoft est plus sûre et plus simple d’utilisation. Toutefois, si votre scénario vous empêche d’utiliser nos bibliothèques, ou si vous souhaitez en savoir plus sur l’implémentation de la plateforme d’identités Microsoft, nous avons une référence du protocole :