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

La plateforme d’identités Microsoft prend en charge l’authentification sur 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 centre d’administration Microsoft Entra 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 :

HTTP

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

Les types d’applications pris en charge par la plateforme d’identité Microsoft sont les suivants :

• Application monopage (SPA)
• Application web
• API web
• Applications mobiles et natives
• Service, démon, script

Applications monopages

De nombreuses applications modernes ont une application monopage (SPA) front-end écrit principalement en JavaScript, souvent avec une infrastructure telle que Angular, React ou Vue. La plateforme d’identités Microsoft prend en charge ces applications à l’aide du protocole OpenID Connect pour l’authentification et de l’un des deux types d’octrois d’autorisation définis par OAuth 2.0. Utilisez le flux de code d’autorisation avec clé de preuve pour échange de code (PKCE) lors du développement de SPA. Ce flux est plus sécurisé que le flux implicite, qui n’est plus recommandé. Pour plus d’informations, consultez Préférez le flux du code d’autorisation.

Le diagramme de flux illustre le flux d’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és Microsoft, et l’utilise pour un jeton d’accès et un jeton d’actualisation à l’aide de requêtes Web intersites. Dans le cas des applications monopages, le jeton d’accès est valide pendant 1 heure et, une fois expiré, l’application doit demander un autre code en utilisant le 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).

Pour voir cela en action, reportez-vous au Guide de démarrage rapide : connexion des utilisateurs dans une application monopage (SPA) et appel de l’API Microsoft Graph à l’aide de JavaScript.

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 :

JSON

// Partial raw ID token
abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9...

// Partial content of a decoded ID token
{
    "name": "Casey Jensen",
    "email": "casey.jensen@onmicrosoft.com",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

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 :

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.

Développer vos connaissances en créant une application web ASP.NET Core pour connecter des utilisateurs et appeler l’API Microsoft Graph

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 Representational State Transfer (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 plus d’informations sur ce scénario, reportez-vous à notre exemple de code.

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 :

HTTP

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9...
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 le jeton d’ID.

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 :

Pour savoir comment sécuriser une API web en utilisant des jetons d’accès OAuth2, consultez les exemples de code d’API web du tutoriel 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 (OBO) 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.

Remarque

Si l’application utilise le 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 Microsoft Entra.

Serveur, démons et scripts

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 utilisant la plateforme d’identités Microsoft.

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

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

Voir aussi

• En savoir plus sur OAuth 2.0 et OpenID Connect
• Inscrire une application