Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Important
À compter du 1er mai 2025, Azure AD B2C ne sera plus disponible pour les nouveaux clients. Pour plus d’informations, consultez notre FAQ.
Azure Active Directory B2C (Azure AD B2C) fournit une identité en tant que service pour vos applications en prenant en charge deux protocoles standard : OpenID Connect et OAuth 2.0. Le service est conforme aux normes, mais deux implémentations de ces protocoles peuvent avoir des différences subtiles.
Les informations contenues dans ce guide sont utiles si vous écrivez votre code en envoyant et en gérant directement des requêtes HTTP, plutôt qu’en utilisant une bibliothèque open source. Nous vous recommandons de lire cette page avant de vous plonger dans les détails de chaque protocole spécifique. Mais si vous connaissez déjà Azure AD B2C, vous pouvez accéder directement aux guides de référence de protocole.
Concepts de base
Chaque application qui utilise Azure AD B2C doit être inscrite dans votre annuaire B2C dans le portail Azure. Le processus d’inscription d’application collecte et affecte quelques valeurs à votre application :
ID d’application qui identifie de façon unique votre application.
URI de redirection ou identificateur de package qui peut être utilisé pour rediriger les réponses vers votre application.
Quelques autres valeurs spécifiques au scénario. Pour plus d’informations, découvrez comment inscrire votre application.
Une fois que vous avez inscrit votre application, elle communique avec Azure AD B2C en envoyant des demandes au point de terminaison :
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/authorize
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/token
Si vous utilisez un domaine personnalisé, remplacez-le {tenant}.b2clogin.com par le domaine personnalisé, par contoso.comexemple, dans les points de terminaison.
Dans presque tous les flux OAuth et OpenID Connect, quatre parties sont impliquées dans l’échange :
Le serveur d’autorisation est le point de terminaison Azure AD B2C. Il gère en toute sécurité tout ce qui est lié aux informations utilisateur et à l’accès. ainsi que les relations de confiance entre les parties des flux. Il est chargé de vérifier l’identité de l’utilisateur, d’accorder et de révoquer l’accès aux ressources et d’émettre des jetons. également connu sous le nom de fournisseur d’identité.
Le propriétaire de la ressource est généralement l’utilisateur final. Il s’agit de la partie propriétaire des données, et elle a le pouvoir d’autoriser des tiers à accéder à ces données ou ressources.
Le client OAuth est votre application. Il est identifié par son ID d’application. Il s’agit généralement de la partie avec laquelle les utilisateurs finaux interagissent. Il demande également des jetons du serveur d’autorisation. Le propriétaire de la ressource doit accorder au client l’autorisation d’accéder à la ressource.
Le serveur de ressources est l’emplacement où réside la ressource ou les données. Il approuve le serveur d’autorisation pour authentifier et autoriser le client OAuth en toute sécurité. Il utilise également les jetons d’accès du porteur pour garantir l’octroi de l’accès à une ressource.
Stratégies et flux d’utilisateurs
Azure AD B2C étend les protocoles OAuth 2.0 et OpenID Connect standard en introduisant des stratégies. Celles-ci permettent à Azure AD B2C d’effectuer beaucoup plus que l’authentification et l’autorisation simples.
Pour vous aider à configurer les tâches d’identité les plus courantes, le portail Azure AD B2C inclut des stratégies prédéfinies et configurables appelées flux d’utilisateurs. Les flux utilisateur décrivent entièrement les expériences d’identité des consommateurs, notamment l’inscription, la connexion et la modification de profil. Les flux utilisateur peuvent être définis dans une interface utilisateur administrative. Ils peuvent être exécutés à l’aide d’un paramètre de requête spécial dans les requêtes d’authentification HTTP.
Les stratégies et les flux utilisateur ne sont pas des fonctionnalités standard d’OAuth 2.0 et OpenID Connect. Vous devez donc prendre le temps de les comprendre. Pour plus d’informations, consultez le guide de référence de flux utilisateur Azure AD B2C.
Jetons
L’implémentation d’Azure AD B2C d’OAuth 2.0 et OpenID Connect utilise largement les jetons du porteur, y compris les jetons du porteur représentés en tant que jetons web JSON (JWTs). Un jeton de porteur est un jeton de sécurité léger qui accorde l’accès « porteur » à une ressource protégée.
Le porteur est n’importe quelle partie qui peut présenter le jeton. Azure AD B2C doit d’abord authentifier une partie avant de pouvoir recevoir un jeton du porteur. Toutefois, si les étapes requises ne sont pas prises pour sécuriser le jeton dans la transmission et le stockage, il peut être intercepté et utilisé par une partie involontaire.
Certains jetons de sécurité ont des mécanismes intégrés qui empêchent les parties non autorisées de les utiliser, mais les jetons du porteur n’ont pas ce mécanisme. Ils doivent être transportés dans un canal sécurisé, tel qu’une sécurité de couche de transport (HTTPS).
Si un jeton de porteur est transmis en dehors d’un canal sécurisé, une partie malveillante peut utiliser une attaque man-in-the-middle pour acquérir le jeton et l’utiliser pour obtenir un accès non autorisé à une ressource protégée. Les mêmes principes de sécurité s’appliquent lorsque les jetons du porteur sont stockés ou mis en cache pour une utilisation ultérieure. Assurez-vous toujours que votre application transmet et stocke les jetons porteurs de manière sécurisée.
Pour des considérations supplémentaires sur la sécurité des jetons porteurs, consultez la section 5 de la RFC 6750.
Des informations supplémentaires sur les différents types de jetons utilisés dans Azure AD B2C sont disponibles dans la référence de jeton Azure AD B2C.
Protocoles
Lorsque vous êtes prêt à passer en revue certains exemples de demandes, vous pouvez commencer par l’un des didacticiels suivants. Chacun correspond à un scénario d’authentification particulier. Si vous avez besoin d’aide pour déterminer quel flux vous convient, consultez les types d’applications que vous pouvez créer à l’aide d’Azure AD B2C.