Types d’application pour la plateforme d’identité Microsoft

La plateforme d’identité Microsoft prend en charge l’authentification pour plusieurs architectures d’application modernes, toutes basées sur des protocoles industriels standard OAuth 2.0 ou OpenID Connect. Cet article décrit les types d’application que vous pouvez générer à l’aide de la plateforme d’identité Microsoft, quelle que soit votre plateforme ou votre langage préférés. Ces informations sont conçues pour vous aider à comprendre les scénarios de haut niveau avant de commencer à manipuler le code dans les scénarios d’application.

Concepts de base

Vous devez inscrire chaque application utilisant la plateforme d’identité Microsoft dans le Portail Azure Inscriptions d’applications. Le processus d’inscription des applications collecte les valeurs suivantes et les affecte à votre application :

  • un ID d’application qui identifie de manière unique votre application ;
  • un URI de redirection que vous pouvez utiliser pour renvoyer les réponses à votre application ;
  • quelques autres valeurs spécifiques au scénario, tels que les types de compte pris en charge.

Pour en savoir plus, découvrez comment inscrire une application.

Une fois inscrite, l’application communique avec la plateforme d’identité Microsoft en transmettant les requêtes au point de terminaison. Nous fournissons les infrastructures et les bibliothèques open source qui gèrent les détails de ces requêtes. Vous avez également la possibilité d’implémenter la logique d’authentification vous-même en créant des requêtes à ces points de terminaison :

https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token

Applications à page unique (Javascript)

De nombreuses applications modernes ont un frontal d’application monopage écrit principalement en JavaScript, souvent avec une infrastructure telle que Angular, React ou Vue. La plateforme d’identité Microsoft prend en charge ces applications avec le protocole OpenID Connect pour l’authentification et soit le flux d’octroi implicite OAuth 2.0, soit le système plus récent avec code d’autorisation OAuth 2.0 + flux PKCE pour l’autorisation (voir ci-dessous).

Le diagramme de flow ci-dessous illustre l’octroi du code d’autorisation OAuth 2,0 (avec des détails sur le PKCE omis), où l’application reçoit un code du point de terminaison authorize de la plateforme d’identité Microsoft, et l’utilise pour un jeton d’accès et un jeton d’actualisation à l’aide de requêtes Web intersites. Le jeton d’actualisation expire toutes les 24 heures, et l’application doit demander un autre code à l’aide du jeton d’actualisation. En plus du jeton d’accès, une id_token qui représente l’utilisateur connecté à l’application cliente est généralement également demandée par le biais du même flux et/ou d’une demande de connexion OpenID distincte (non illustrée ici).

Diagram showing the OAuth 2 authorization code flow between a single-page app and the security token service endpoint.

Pour voir ce scénario en action, consultez le didacticiel : Connecter les utilisateurs et appeler l’API Microsoft Graph à partir d’une application monopage JavaScript à l’aide d’un flux de code d’autorisation.

Flux de code d’autorisation et flux implicite

Pour l’essentiel de l’historique d’OAuth 2.0, le flux implicite était la méthode recommandée pour générer des applications monopages. Avec la suppression des cookies tiers et une plus grande attention portée sur les problèmes de sécurité liés au flux implicite, nous avons adopté vers le code d’autorisation pour les applications monopages.

Pour garantir la compatibilité de votre application dans Safari et dans d’autres navigateurs prenant en charge la confidentialité, nous recommandons d’utiliser le flux de code d’autorisation plutôt que le flux implicite.

les applications web

Pour les applications web (.NET, PHP, Java, Ruby, Python, Node, etc.) auxquelles l’utilisateur accède par le biais d’un navigateur, vous pouvez utiliser OpenID Connect pour la connexion de l’utilisateur. Dans OpenID Connect, l’application web reçoit un jeton d’ID. Un jeton d’ID est un jeton de sécurité qui vérifie l’identité de l’utilisateur et fournit des informations le concernant sous la forme de revendications :

// Partial raw ID token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded ID token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

Pour en savoir plus sur les différents types de jetons utilisés dans la plateforme d’identité Microsoft, consultez les articles de référence sur le jeton d’accès et l’id_token.

Dans les applications de serveur web, le flux d’authentification de connexion respecte cette procédure de niveau supérieur :

Shows the web app authentication flow

Vous pouvez vérifier l’identité de l’utilisateur en validant le jeton d’ID avec une clé de signature publique reçue de la plateforme d’identité Microsoft. Un cookie de session qui peut être utilisé pour identifier l’utilisateur sur les requêtes de page suivantes est défini.

Pour voir ce scénario en action, essayez les exemples de code du scénario d'application web qui connecte des utilisateurs.

En plus de la connexion simple, une application de serveur web peut également nécessiter l’accès à un autre service Web, comme une API REST. Dans ce cas, l’application de serveur web s’engager dans un flux OpenID Connect et OAuth 2.0 à l’aide du flux de code d’autorisation OAuth 2.0. Pour en savoir plus sur ce scénario, découvrez comment la bien démarrer avec les applications web et des API web.

API Web

Vous pouvez utiliser la plateforme d’identité Microsoft pour sécuriser des services web, comme l’API web RESTful de votre application. Les API web peuvent être implémentées dans de nombreuses plateformes et langages. Elles peuvent également être implémentées à l’aide de déclencheurs HTTP dans Azure Functions. En lieu et place des jetons d’ID et des cookies de session, une API web utilise les jetons d’accès OAuth 2.0 pour sécuriser les données et authentifier les requêtes entrantes. L’appelant d’une API web ajoute un jeton d’accès dans l’en-tête d’autorisation d’une requête HTTP de la manière suivante :

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
Accept: application/json
...

L’API web utilise le jeton d’accès pour vérifier l’identité de l’appelant de l’API et extraire des informations le concernant à partir de revendications encodées dans le jeton d’accès. Pour en savoir plus sur les différents types de jetons utilisés dans la plateforme d’identité Microsoft, consultez les articles de référence sur le jeton d’accès et l’id_token.

Une API web peut octroyer aux utilisateurs la possibilité d’accepter/de refuser des fonctionnalités ou données spécifiques en exposant des autorisations (également appelées étendues). Pour qu’une application appelante puisse acquérir l’autorisation à une étendue, l’utilisateur doit accepter l’étendue au cours d’un flux. La plateforme d’identité demande l’autorisation à l’utilisateur, puis enregistre ces autorisations dans l’ensemble des jetons d’accès reçus par l’API web. L’API web valide les jetons d’accès qu’elle reçoit à chaque appel et procède à des vérifications d’autorisation.

Une API web peut recevoir des jetons d’accès de tous types d’applications, notamment des applications de serveur web, des applications de bureau et mobiles, des applications de page unique, des démons côté serveur, et même d’autres API web. Le flux de haut niveau d'une API web se présente comme suit :

Shows the web API authentication flow

Pour savoir comment sécuriser une API web avec des jetons d’accès OAuth2, consultez les exemples de code d’API web du scénario d’API web protégée.

Dans de nombreux cas, les API web doivent également envoyer des demandes à d’autres API web en aval, sécurisées par la plateforme d’identité Microsoft. Pour ce faire, elles peuvent utiliser le flux Au nom de d’Azure AD, qui permet à l’API web d’échanger un jeton d’accès entrant contre un autre jeton d’accès, à utiliser pour les requêtes sortantes. Pour en savoir plus, voir Plateforme d’identité Microsoft et flux On-Behalf-Of OAuth 2.0.

Applications mobiles et natives

Les applications installées sur un appareil, comme les applications de bureau et les applications mobiles nécessitent bien souvent un accès à des services principaux ou à des API web, qui stockent les données et exécutent des fonctions pour le compte d’un utilisateur. Ces applications peuvent ajouter des fonctionnalités de connexion et d’autorisation à des services principaux à l’aide du flux de code d’autorisation OAuth 2.0.

Dans ce flux, l’application reçoit un code d’autorisation à partir de la plateforme d’identité Microsoft lorsque l’utilisateur se connecte. Le code d'autorisation représente l'autorisation de l'application d'appeler les services principaux pour le compte de l'utilisateur connecté. L’application peut ensuite échanger le code d’autorisation en arrière-plan contre un jeton d’accès et un jeton d’actualisation OAuth 2.0. L’application peut utiliser le jeton d’accès pour s’authentifier sur des API web dans des requêtes HTTP et solliciter le jeton d’actualisation afin de récupérer de nouveaux jetons d’accès une fois les anciens expirés.

Shows the native app authentication flow

Notes

Si l’application utilise l’application System WebView par défaut, consultez les informations concernant la fonctionnalité « Confirmer ma connexion » et le code d’erreur AADSTS50199 dans Codes d’erreur d’authentification et d’autorisation Azure AD.

Applications démons et côté serveur

Les applications qui contiennent des processus de longue durée ou qui fonctionnent sans interaction d’un utilisateur doivent également disposer d’un moyen d’accès aux ressources sécurisées, comme les API web. Ces applications peuvent s'authentifier et récupérer des jetons à l'aide de l'identité d'application plutôt qu'avec l'identité déléguée d'un utilisateur avec le flux des informations d'identification du client OAuth 2.0. Vous pouvez prouver l’identité de l’application à l’aide d’une clé secrète client ou d’un certificat. Pour plus d’informations, consultez Application console démon .NET Core utilisant la plateforme d’identité Microsoft.

Dans ce flux, l’application interagit directement avec le point de terminaison /token pour obtenir un accès :

Shows the daemon app authentication flow

Pour créer une application démon, consultez la documentation sur les informations d’identification des clients ou consultez un exemple d’application .NET.

Étapes suivantes

À présent que vous êtes familiarisé avec les types d’applications que la plateforme d’identité Microsoft prend en charge, apprenez-en davantage sur OAuth 2.0 et OpenID Connect afin de comprendre les composants de protocole utilisés par les différents scénarios.