Authentification et autorisation dans Microsoft Entra ID
Microsoft Entra ID prend en charge les protocoles d’identité modernes, notamment OAuth 2.0 et OpenID Connect. Les bibliothèques telles que MSAL4J aident les applications à utiliser ces protocoles sans implémenter elles-mêmes chaque interaction de protocole.
Dans le scénario du portail d’entreprise, Microsoft Entra ID est le fournisseur d’identité. Le portail s’appuie sur celui-ci pour authentifier les comptes et émettre des jetons, mais le portail a toujours des responsabilités pour ses propres sessions et décisions d’autorisation.
Authentification
L’authentification établit et vérifie une identité. Pour une application orientée utilisateur, elle répond à la question « Qui est cet utilisateur ? »
OpenID Connect ajoute une couche d’identité à OAuth 2.0. Une application peut recevoir un jeton d’ID contenant des revendications concernant un utilisateur authentifié et l’événement d’authentification. Le jeton d’ID est destiné à l’application cliente ; ce n'est pas le jeton que l'application envoie à Microsoft Graph.
Autorisation
L’autorisation détermine si une identité a l’autorisation d’effectuer une opération ou d’accéder aux données. Il répond à la question : « Qu’est-ce que cet utilisateur ou cette application est autorisé à faire ? »
OAuth 2.0 fournit des flux permettant d’obtenir des jetons d’accès pour les API protégées. Dans le scénario du portail, un jeton d’accès Microsoft Graph permet au portail de demander des données spécifiques pour le compte de l’utilisateur connecté, sous réserve des autorisations accordées.
Le tableau suivant distingue les responsabilités d’authentification et d’autorisation du portail.
| Préoccupation | Exemple dans le portail |
|---|---|
| Authentification | Microsoft Entra ID authentifie un compte et le portail reçoit un jeton d’ID via le flux de connexion. |
| Autorisation de l’API | Un jeton d’accès Microsoft Graph contient une autorisation déléguée permettant de lire le profil de l’utilisateur connecté. |
| Autorisation de l’application | Le portail applique toutes les règles supplémentaires qui contrôlent l’accès à ses propres pages ou opérations métier. |
L’authentification réussie n’accorde pas automatiquement l’accès à chaque page ou API. Par exemple, l’appartenance au locataire seul n’établit pas qu’une personne est un employé.
Enregistrement d’application
Une inscription d’application décrit une application pour Microsoft Entra ID. Il établit les paramètres d’identité et d’enregistrement de l’application, tels que son audience de connexion et ses URI de redirection. Les inscriptions peuvent être gérées via le portail Azure, les Azure CLI ou les API Microsoft Graph ; aucune inscription n’est créée dans ce module.
Les types de compte pris en charge définissent l’audience de connexion :
- Les comptes de cet annuaire organisationnel identifient uniquement un public à locataire unique, y compris les comptes d’utilisateur et d’invité dans le locataire sélectionné.
- Comptes dans n’importe quel annuaire organisationnel autorise les comptes provenant de locataires Microsoft Entra dans une architecture multilocataire.
- Les comptes dans n’importe quel annuaire organisationnel et comptes de Microsoft personnels autorisent également des comptes de Microsoft personnels.
- Les comptes de Microsoft personnels limitent l’audience aux comptes de Microsoft personnels, tels que les comptes Outlook.com.
L’inscription possède un ID d’application (client) qui identifie l’application dans les demandes de protocole. Une application web confidentielle utilise également des informations d’identification d’application pour s’authentifier lors de l’acquisition de jetons. L’ID client et les informations d’identification ont des objectifs différents : un identificateur n’est pas un secret.
L’unité suivante interprète un exemple d’inscription et connecte ses paramètres aux exemples de code.