Types d’applications pouvant être utilisés dans Active Directory B2C

Azure Active Directory B2C (Azure AD B2C) prend en charge l’authentification pour diverses architectures d’applications modernes. Tous sont basés sur les protocoles standard de l’industrie OAuth 2.0 ou OpenID Connect. Cet article décrit les types d’applications que vous pouvez créer, indépendamment du langage ou de la plate-forme que vous préférez. Il vous aide également à comprendre les scénarios de haut niveau avant de commencer à créer des applications.

Chaque application qui utilise Azure AD B2C doit être inscrite dans votre locataire Azure AD B2C à l’aide du portail Azure. Le processus d’enregistrement de la demande collecte et attribue des valeurs, telles que :

• Un ID d’application qui identifie de manière unique votre application.
• Une URL de réponse qui peut être utilisée pour rediriger les réponses vers votre application.

Chaque demande envoyée à Azure AD B2C spécifie un flux d’utilisateurs (une stratégie intégrée) ou une stratégie personnalisée qui contrôle le comportement d’Azure AD B2C. Les deux types de stratégies vous permettent de créer un ensemble d’expériences utilisateur hautement personnalisables.

L’interaction de chaque application suit un schéma similaire de haut niveau :

1. L’application dirige l’utilisateur vers le point de terminaison v2.0 pour exécuter une stratégie.
2. L’utilisateur exécute la stratégie conformément à la définition de la stratégie.
3. L’application reçoit un jeton de sécurité du point de terminaison v2.0.
4. L’application utilise le jeton de sécurité pour accéder à des informations protégées ou à une ressource protégée.
5. Le serveur de ressources valide le jeton de sécurité pour vérifier que l’accès peut être accordé.
6. L’application actualise régulièrement le jeton de sécurité.

Ces étapes peuvent différer légèrement en fonction du type d’application que vous créez.

Applications Web

Pour les applications web (y compris .NET, PHP, Java, Ruby, Python et Node.js) qui sont hébergées sur un serveur web et accessibles via un navigateur, Azure AD B2C prend en charge OpenID Connect pour toutes les expériences utilisateur. Dans l’implémentation Azure AD B2C d’OpenID Connect, votre application web lance des expériences utilisateur en émettant des demandes d’authentification à Microsoft Entra ID. Le résultat de la demande est un id_token. Ce jeton de sécurité représente l’identité de l’utilisateur. Il fournit également des informations sur l’utilisateur sous forme de réclamations :

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

Pour en savoir plus sur les types de jetons et de revendications disponibles pour une application, consultez la référence sur les jetons Azure AD B2C.

Dans une application web, chaque exécution d’une politique effectue les étapes de haut niveau suivantes :

1. L’utilisateur navigue sur l’application web.
2. L’application web redirige l’utilisateur vers Azure AD B2C en indiquant la stratégie à exécuter.
3. L’utilisateur exécute la stratégie.
4. Azure AD B2C renvoie un id_token au navigateur.
5. Le id_token est posté dans l’URI de redirection.
6. Le id_token est validé et un cookie de session est défini.
7. Une page sécurisée est renvoyée à l’utilisateur.

La validation de la id_token à l’aide d’une clé de signature publique reçue de Microsoft Entra ID est suffisante pour vérifier l’identité de l’utilisateur. Ce processus définit également un cookie de session qui peut être utilisé pour identifier l’utilisateur lors des demandes de page ultérieures.

Pour voir ce scénario en action, essayez l’un des exemples de code de connexion à l’application web dans notre section Mise en route.

En plus de faciliter la connexion simple, une application web peut également avoir besoin d’accéder à un service web principal. Dans ce cas, l’application web peut effectuer un flux OpenID Connect légèrement différent et acquérir des jetons à l’aide de codes d’autorisation et de jetons d’actualisation. Ce scénario est décrit dans la section API Web suivante.

Applications monopage

De nombreuses applications web modernes sont créées en tant qu’applications monopage côté client (« SPAs »). Les développeurs les écrivent à l’aide de JavaScript ou d’un framework SPA tel que Angular, Vue ou React. Ces applications s’exécutent sur un navigateur web et présentent des caractéristiques d’authentification différentes de celles des applications web classiques côté serveur.

Azure AD B2C fournit deux options pour permettre aux applications monopage de connecter des utilisateurs et d’obtenir des jetons pour accéder aux services principaux ou aux API web :

Flux de code d’autorisation (avec PKCE)

Le flux de code d’autorisation OAuth 2.0 (avec PKCE) permet à l’application d’échanger un code d’autorisation pour les jetons d’ID afin de représenter l’utilisateur authentifié et les jetons d’accès nécessaires pour appeler des API protégées. En outre, il retourne des jetons d’actualisation qui fournissent un accès à long terme aux ressources pour le compte des utilisateurs sans nécessiter d’interaction avec ces utilisateurs.

Nous avons recommandé cette approche. L’utilisation de jetons d’actualisation à durée de vie limitée aide votre application à s’adapter aux limitations de confidentialité des cookies de navigateur modernes, telles que Safari ITP.

Pour tirer parti de ce flux, votre application peut utiliser une bibliothèque d’authentification qui le prend en charge, comme MSAL.js 2.x.

Octroi de flux implicite

Certaines bibliothèques, comme MSAL.js 1.x, ne prennent en charge que le flux d’octroi implicite ou votre application est implémentée pour utiliser le flux implicite. Dans ces cas, Azure AD B2C prend en charge le flux implicite OAuth 2.0. Le flux d’octroi implicite permet à l’application d’obtenir des jetons d’ID et d’accès. Contrairement au flux de code d’autorisation, le flux d’octroi implicite ne retourne pas de jeton d’actualisation.

Ce flux d’authentification n’inclut pas de scénarios d’application qui utilisent des infrastructures JavaScript multiplateformes telles que Electron et React-Native. Ces scénarios nécessitent d’autres fonctionnalités d’interaction avec les plateformes natives.

API Web

Vous pouvez utiliser Azure AD B2C pour sécuriser des services web tels que l’API web RESTful de votre application. Les API Web peuvent utiliser OAuth 2.0 pour sécuriser leurs données, en authentifiant les requêtes HTTP entrantes à l’aide de jetons. L’appelant d’une API web ajoute un token dans l’en-tête d’autorisation d’une requête HTTP :

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

L’API web peut ensuite utiliser le jeton pour vérifier l’identité de l’appelant de l’API et pour extraire des informations sur l’appelant à partir des revendications encodées dans le jeton. Pour en savoir plus sur les types de jetons et de revendications disponibles pour une application, consultez la référence des jetons Azure AD B2C.

Une API web peut recevoir des jetons de nombreux types de clients, notamment des applications web, des applications de bureau et mobiles, des applications à page unique, des démons côté serveur et d’autres API web. Voici un exemple de flux complet pour une application web qui appelle une API web :

1. L’application web exécute une stratégie et l’utilisateur termine l’expérience utilisateur.
2. Azure AD B2C renvoie un code (OpenID Connect) id_token et un code d’autorisation au navigateur.
3. Le navigateur publie le id_token et le code d'autorisation vers l'URI de redirection.
4. Le serveur web valide le cookie et définit un cookie de id_token session.
5. Le serveur web demande à Azure AD B2C un access_token en lui fournissant le code d’autorisation, l'ID du client d'application et les informations d’identification du client.
6. Les access_token et refresh_token sont renvoyés au serveur Web.
7. L'API web est appelée avec access_token dans un en-tête d'autorisation.
8. L’API web valide le jeton.
9. Les données sécurisées sont renvoyées à l’application Web.

Pour en savoir plus sur les codes d’autorisation, les jetons d’actualisation et les étapes d’obtention des jetons, consultez la page sur le protocole OAuth 2.0.

Pour savoir comment sécuriser une API web à l’aide d’Azure AD B2C, consultez les tutoriels sur l’API web dans notre section Prise en main.

Applications mobiles et natives

Les applications installées sur des appareils, telles que les applications mobiles et de bureau, ont souvent besoin d’accéder à des services back-end ou à des API Web pour le compte des utilisateurs. Vous pouvez ajouter des expériences de gestion des identités personnalisées à vos applications natives et appeler en toute sécurité des services back-end à l’aide d’Azure AD B2C et du flux de code d’autorisation OAuth 2.0.

Dans ce flux, l’application exécute des stratégies et reçoit un authorization_code de Microsoft Entra une fois que l’utilisateur a terminé la stratégie. Le authorization_code représente l’autorisation de l’application d’appeler les services back-end au nom de l’utilisateur actuellement connecté. L’application peut alors échanger le authorization_code en arrière-plan contre un access_token et un refresh_token. L'application peut utiliser access_token pour s'authentifier auprès d'une API web back-end dans les requêtes HTTP. Il peut également utiliser le refresh_token pour obtenir un nouveau lorsqu’un ancien access_token expire.

Démons/applications côté serveur

Les applications qui contiennent des processus de longue durée ou qui fonctionnent sans la présence d’un utilisateur ont également besoin d’un moyen d’accéder à des ressources sécurisées telles que des API Web. Ces applications peuvent s’authentifier et obtenir des jetons à l’aide de leurs identités (plutôt que de l’identité déléguée d’un utilisateur) et à l’aide du flux d’informations d’identification du client OAuth 2.0. Le flux d’informations d’identification du client n’est pas le même que celui avec emprunt d’identité, et celui-ci ne doit pas être utilisé pour l’authentification de serveur à serveur.

Pour Azure AD B2C, le flux d’informations d’identification du client OAuth 2.0 est actuellement en préversion publique. Toutefois, vous pouvez configurer le flux d’informations d’identification du client à l’aide de l’ID Microsoft Entra et du point de terminaison de la plateforme /token d’identités Microsoft (https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token) pour une application Microsoft Graph ou votre propre application. Pour plus d’informations, consultez l’article de référence sur les jetons Microsoft Entra.

Types d’applications non pris en charge

Chaînes d’API web (flux On-Behalf-Of)

De nombreuses architectures incluent une API web qui doit appeler une autre API web en aval, où les deux sont sécurisées par Azure AD B2C. Ce scénario est courant dans les clients natifs qui disposent d’un back-end d’API Web et qui appellent un service en ligne Microsoft tel que l’API Microsoft Graph.

Ce scénario d'API Web en chaîne peut être pris en charge à l'aide de l'octroi d'informations d'identification du porteur JWT OAuth 2.0, également connu sous le nom de flux au nom de. Toutefois, le flux On-Behalf-Of n’est pas implémenté dans Azure AD B2C pour l’instant.

Étapes suivantes

En savoir plus sur les stratégies intégrées fournies par les flux d’utilisateurs dans Azure Active Directory B2C.