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

  • Article

Azure Active Directory B2C (Azure AD B2C) prend en charge l’authentification pour une gamme d’architectures d’applications modernes. Toutes sont basées sur les protocoles standard OAuth 2.0 ou OpenID Connect. Cet article décrit les types d’applications que vous pouvez créer, indépendamment de votre langage et de votre plateforme préférés. Il vous permet également de comprendre les principaux scénarios avant de commencer à créer des applications.

Chaque application qui utilise Azure AD B2C doit être inscrite auprès de votre locataire Azure AD B2C dans le portail Azure. Le processus d’inscription des applications collecte et attribue des valeurs, par exemple :

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

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

Le mode d’interaction de chaque application suit un modèle général similaire :

  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 en fonction de la définition de celle-ci.
  3. L’application reçoit un jeton de sécurité de la part du point de terminaison v2.0.
  4. L’application utilise le jeton de sécurité pour accéder aux informations ou à la ressource protégées.
  5. Le serveur de ressources valide le jeton de sécurité afin de garantir l’octroi de l’accès.
  6. L’application actualise régulièrement le jeton de sécurité.

Ces étapes peuvent varier légèrement selon le type d’application que vous créez.

Applications web

Pour les applications web (notamment .NET, PHP, Java, Ruby, Python et Node.js) qui sont hébergées sur un serveur web et accessibles par le biais d’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 déclenche les expériences utilisateur en envoyant des demandes d’authentification à Microsoft Entra ID. Le résultat de la demande est un élément 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 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 plus d’informations sur les différents types de jetons et de revendications disponibles pour une application, consultez la documentation de référence sur les jetons Azure AD B2C.

Dans les applications web, chaque exécution d’une stratégie suit cette procédure générale :

  1. L’utilisateur accède à 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 retourne un id_token au navigateur.
  5. Le id_token est publié 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 retournée à l’utilisateur.

La validation de l’élément id_token à l’aide d’une clé de signature publique provenant 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 sur les demandes de page suivantes.

Pour voir ce scénario à l’œuvre, exécutez l’un des exemples de code de connexion d’application web de la section Prise en main.

Outre la simplification des connexions, une application web peut également nécessiter l’accès à un service web backend. Dans ce cas, l’application web peut exécuter 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 représenté dans la section API Webci-après.

Applications monopages

De nombreuses applications web modernes sont créées en tant qu’applications monopages (« SPA ») côté client. Les développeurs les écrivent à l’aide de JavaScript ou d’un framework d’application monopage, comme 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 propose deux options qui permettent aux applications monopages d’effectuer la connexion des utilisateurs, et d’obtenir des jetons pour accéder aux services back-end 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 obtenir des jetons d’ID afin de représenter l’utilisateur authentifié et des jetons d’accès nécessaires pour appeler des API protégées. De plus, il retourne des jetons d’actualisation qui fournissent à votre application un accès à long terme à des ressources au nom d’utilisateurs sans nécessiter l’intervention de ces utilisateurs.

Nous recommandons cette approche. Le fait d’avoir des jetons d’actualisation à durée de vie limitée permet à votre application de s’adapter aux restrictions de confidentialité des cookies des navigateurs modernes, tels que Safari ITP.

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

Authentification des applications monopages

Octroi de flux implicite

Certaines bibliothèques, comme MSAL.js 1.x, prennent uniquement en charge le workflow 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.

Nous ne recommandons pas cette approche.

Ce flux d’authentification n’inclut pas de scénarios d’application utilisant des frameworks JavaScript multiplateformes, tels qu’Electron et React-Native. Ces scénarios exigent davantage de capacités pour l’interaction avec les plateformes natives.

API Web

Vous pouvez utiliser Azure AD B2C pour sécuriser les services web, comme 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 jeton 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 extraire les informations à son sujet, à partir des revendications encodées dans le jeton. Pour plus d’informations sur les différents types de jetons et de revendications disponibles pour une application, voir la référence sur les jetons Azure AD B2C.

Une API web peut recevoir des jetons de tous types de clients, notamment des applications web, des applications de bureau et mobiles, des applications monopages, des démons côté serveur, et même d’autres API web. Voici un exemple de flux complet d’une application web appelant 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 id_token (OpenID Connect) et un code d’autorisation au navigateur.
  3. Le navigateur publie le id_token et le code d’autorisation à l’URI de redirection.
  4. Le serveur web valide le id_token et définit un cookie de 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. Le access_token et le refresh_token sont retournés au serveur web.
  7. L’API web est appelée avec le access_token dans un en-tête d’autorisation.
  8. L’API web valide le jeton.
  9. Les données sécurisées sont retournées à l’application web.

Pour plus d’informations sur les codes d’autorisation, les jetons d’actualisation et les étapes d’obtention des jetons, voir l’article concernant le protocole OAuth 2.0.

Pour savoir comment sécuriser une API web avec Azure AD B2C, consultez les didacticiels d’API web dans notre section Prise en main.

Applications mobiles et natives

Les applications installées sur des appareils, comme les applications de bureau et les applications mobiles, nécessitent souvent que vous accédiez aux services backend ou aux API web pour le compte de l’utilisateur. Vous pouvez ajouter des expériences personnalisées de gestion des identités à vos applications natives et appeler de manière sécurisée les services backend à 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 ID une fois que l’utilisateur a exécuté la stratégie. authorization_code représente l’autorisation de l’application à appeler les services backend pour le compte de l’utilisateur actuellement connecté. L’application peut ensuite échanger authorization_code en arrière-plan contre access_token et refresh_token. L’application peut utiliser access_token pour s’authentifier auprès d’une API web backend dans les requêtes HTTP. Elle peut également utiliser l’élément refresh_token pour obtenir un nouvel élément access_token lorsque le précédent arrive à expiration.

Démons et applications côté serveur

Les applications qui contiennent des processus de longue durée ou qui fonctionnent sans la présence 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 obtenir des jetons à l’aide de leurs identités (plutôt qu’avec l’identité déléguée d’un utilisateur), et à l’aide du flux des 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. Néanmoins, vous pouvez configurer le flux d’informations d’identification client à l’aide de Microsoft Entra ID et du point de terminaison /token de la plateforme d’identité 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 Documentation 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, toutes deux sécurisées par Azure AD B2C. Ce scénario est courant dans les clients natifs qui disposent d’une API web principale et appellent un service en ligne Microsoft, comme l’API Microsoft Graph.

Ce scénario d’API web chaînée peut être pris en charge à l’aide de la concession des informations d’identification du porteur OAuth 2.0 Jwt, également appelé flux On-Behalf-Of. 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 Flux d’utilisateur dans Azure Active Directory B2C.