Partage via

Plateforme d’identités Microsoft et informations d’identification du mot de passe du propriétaire de la ressource OAuth 2.0

  • Article

La plateforme d’identité Microsoft prend en charge l’octroi des informations d’identification de mot de passe du propriétaire des ressources OAuth 2.0, qui permet à une application de connecter l’utilisateur en gérant directement son mot de passe. Cet article explique comment programmer directement contre le protocole dans votre application. Dans la mesure du possible, nous vous recommandons d’utiliser les bibliothèques d’authentification Microsoft (MSAL) prises en charge au lieu d’acquérir des jetons et d’appeler des API web sécurisées. Examinez également les exemples d’applications qui utilisent MSAL.

Avertissement

Microsoft vous recommande de ne pas utiliser le flux ROPC ; il n’est pas compatible avec l’authentification multifacteur (MFA). Dans la plupart des scénarios, des alternatives plus sécurisées sont disponibles et recommandées. Ce flux nécessite un degré de confiance très élevé dans l’application et comporte des risques qui ne sont pas présents dans d’autres flux. Vous ne devez utiliser ce flux que lorsque des flux plus sécurisés ne sont pas viables.

Important

  • La plateforme d’identité Microsoft prend en charge l’octroi ROPC uniquement pour les locataires Microsoft Entra, et non pour les comptes personnels. Cela signifie que vous devez utiliser un point de terminaison spécifique au locataire (https://login.microsoftonline.com/{TenantId_or_Name}) ou le point de terminaison organizations.
  • Les comptes personnels qui sont invités sur un locataire Microsoft Entra ne peuvent pas utiliser le flux ROPC.
  • Les comptes qui n’ont pas de mots de passe ne peuvent pas se connecter avec ROPC, ce qui signifie que les fonctionnalités telles que la connexion SMS, FIDO et l’application Authenticator ne fonctionne pas avec ce flux. Si votre application ou vos utilisateurs nécessitent ces fonctionnalités, utilisez un type d’octroi autre que ROPC.
  • Si les utilisateurs doivent utiliser l’authentification multifacteur (MFA) pour se connecter à l’application, ils seront au lieu de cela bloqués.
  • ROPC n’est pas pris en charge dans les scénarios de fédération des identités hybrides (par exemple, Microsoft Entra ID et AD FS utilisés pour authentifier des comptes locaux). Si les utilisateurs sont redirigés vers une page complète vers un fournisseur d’identité local, l’ID Microsoft Entra n’est pas en mesure de tester le nom d’utilisateur et le mot de passe sur ce fournisseur d’identité. L’authentification directe est toutefois prise en charge avec ROPC.
  • Une exception à un scénario de fédération d’identité hybride est la suivante : la stratégie de découverte du domaine d’accueil avec AllowCloudPasswordValidation définie sur TRUE permet au flux ROPC de fonctionner pour les utilisateurs fédérés lorsqu’un mot de passe local est synchronisé avec le cloud. Pour plus d’informations, consultez Activer l’authentification ROPC directe des utilisateurs fédérés pour les applications héritées.
  • Les mots de passe avec des espaces blancs de début ou de fin ne sont pas pris en charge par le flux ROPC.

Comment migrer à partir de ROPC

À mesure que l'authentification multifacteur devient plus répandue, certaines API web Microsoft acceptent uniquement les jetons d’accès quand ils ont satisfait aux exigences AMF. Les applications et les plateformes de test qui s’appuient sur ROPC seront verrouillées. Microsoft Entra n’émet pas le jeton, ou la ressource rejette la demande.

Si vous utilisez ROPC pour acquérir des jetons pour appeler des API en aval protégées, migrez vers une stratégie d’acquisition de jetons sécurisée.

Lorsque le contexte utilisateur est disponible

Si un utilisateur final doit accéder à une ressource, l’application cliente qui agit en son nom doit utiliser une forme d’authentification interactive. L’utilisateur final ne peut être soumis à l’authentification multifacteur que lorsqu’une invitation s’affiche dans le navigateur.

  • Pour les applications web :
    • Si l’authentification est effectuée sur le serveur frontal, consultez Application monopage.
    • Si l’authentification est effectuée dans le serveur principal, consultez applications web.
  • Les API web ne peuvent pas afficher un navigateur. Au lieu de cela, ils doivent retourner un défi à l’application cliente. Pour plus d’informations, consultez API web et Mettre les utilisateurs au défi dans les API web.
  • Les applications de bureau doivent utiliser l’authentification basée sur un répartiteur. Les courtiers utilisent l’authentification basée sur le navigateur, afin qu’ils puissent appliquer l’authentification multifacteur et assurer une posture de sécurité maximale.
  • Les applications mobiles doivent également être configurées pour utiliser l’authentification basée sur broker (Authenticator, Portail d’entreprise).

Quand le contexte utilisateur n’est pas disponible

Exemples de scénarios où aucun contexte utilisateur n’est impliqué peut être, mais n’est pas limité à, les éléments suivants :

  • Un script s’exécutant dans le cadre d’un pipeline CI.
  • Un service qui a besoin d’appeler une ressource pour le compte de lui-même, sans détails utilisateur.

Les développeurs d’applications doivent utiliser l'authentification du principal de service , qui est illustrée dans les exemples de service d'arrière-plan . L’authentification multifacteur ne s’applique pas aux principaux de service.

Il existe plusieurs façons de s’authentifier en tant que principal de service :

  • Si votre application s’exécute sur l’infrastructure Azure, utilisez Managed Identity. L’identité managée élimine la surcharge liée à la maintenance et à la rotation des secrets et des certificats.
  • Si votre application s’exécute sur un système géré par un autre fournisseur d’identité conforme à OAuth2, tel que GitHub, utilisez informations d’identification d’identité fédérée.
  • Si vous ne pouvez pas utiliser une identité managée ou une identité fédérée, utilisez un identifiant de certificat .

Avertissement

N’utilisez pas l’authentification du principal de service lorsqu’un contexte utilisateur est disponible. L’accès à l’application uniquement est intrinsèquement à privilège élevé, accordant souvent un accès à l’échelle du locataire et permettant potentiellement à un mauvais acteur d’accéder aux données client pour n’importe quel utilisateur.

Diagramme de protocole

Le diagramme suivant montre le flux ROPC.

Diagramme montrant le flux du mot de passe du détenteur de la ressource

Demande d’autorisation

Le flux ROPC est une requête unique ; il envoie les informations d’identification du client et les informations d’identification de l’utilisateur au fournisseur d’identité et reçoit des jetons en retour. Le client doit demander l’adresse e-mail de l’utilisateur (UPN) et le mot de passe avant de le faire. Immédiatement après une demande réussie, le client doit ignorer en toute sécurité les informations d’identification de l’utilisateur à partir de la mémoire. Il ne doit jamais les sauver.

// Line breaks and spaces are for legibility only.  This is a public client, so no secret is required.

POST {tenant}/oauth2/v2.0/token
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=user.read%20openid%20profile%20offline_access
&username=MyUsername@myTenant.com
&password=SuperS3cret
&grant_type=password
Paramètre Condition Description
tenant Obligatoire Locataire de l’annuaire auquel vous voulez connecter l’utilisateur. Le locataire peut être au format GUID ou sous forme de nom convivial. Toutefois, son paramètre ne peut pas être défini sur common ou consumers, mais peut être défini sur organizations.
client_id Obligatoire L’ID d’application (client) que la page Centre d’administration Microsoft Entra : Inscriptions d’applications a attribué à votre application.
grant_type Obligatoire Cette propriété doit être définie sur password.
username Obligatoire Adresse e-mail de l’utilisateur.
password Obligatoire Mot de passe de l’utilisateur.
scope Recommandé Une liste (séparée par des espaces) d’étendues, ou d’autorisations, exigées par l’application. Dans un flux interactif, l’administrateur ou l’utilisateur doit consentir à ces étendues à l’avance.
client_secret Parfois requis Si votre application est un client public, la client_secret ou client_assertion ne peut pas être incluse. Si l’application est un client confidentiel, elle doit être incluse.
client_assertion Parfois requis Une autre forme de client_secret, générée à l’aide d’un certificat. Pour plus d’informations, consultez Informations d’identification de certificat.

Réponse d’authentification réussie

L’exemple suivant montre une réponse de jeton réussie :

{
    "token_type": "Bearer",
    "scope": "User.Read profile openid email",
    "expires_in": 3599,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD..."
}
Paramètre Format Description
token_type Chaîne Toujours défini sur Bearer.
scope Chaînes séparées par espace Si un jeton d’accès a été retourné, ce paramètre répertorie les étendues pour laquelle le jeton d’accès est valide.
expires_in int Nombre de secondes pendant lesquelles le jeton d’accès inclus est valide.
access_token Chaîne opaque Émise pour les étendues qui ont été demandées.
id_token JWT Émis si le paramètre scope d’origine incluait l’étendue openid.
refresh_token Chaîne opaque Émis si le paramètre de scope d’origine inclus offline_access.

Vous pouvez utiliser le jeton d’actualisation pour acquérir de nouveaux jetons d’accès et des jetons d’actualisation à l’aide du même flux décrit dans la documentation flux de code OAuth.

Avertissement

N’essayez pas de valider ou de lire des jetons pour toute API que vous ne possédez pas, y compris les jetons de cet exemple, dans votre code. Les jetons pour les services Microsoft peuvent utiliser un format spécial qui ne sera pas validé en tant que JWT et peut également être chiffré pour les utilisateurs consommateurs (compte Microsoft). Bien que la lecture des jetons soit un outil de débogage et d’apprentissage utile, ne prenez pas de dépendances sur cela dans votre code ou supposez des spécificités sur les jetons qui ne sont pas pour une API que vous contrôlez.

Réponse d’erreur

Si l’utilisateur n’a pas fourni le nom d’utilisateur ou le mot de passe correct, ou si le client n’a pas reçu le consentement demandé, l’authentification échoue.

Erreur Description Action du client
invalid_grant Échec de l’authentification Les informations d’identification étaient incorrectes ou le client n’a pas le consentement pour les étendues demandées. Si les étendues ne sont pas accordées, une erreur consent_required est retournée. Pour résoudre cette erreur, le client doit envoyer l’utilisateur à une invite interactive à l’aide d’une vue web ou d’un navigateur.
invalid_request La demande a été incorrectement construite Le type d’octroi n’est pas pris en charge sur les contextes d’authentification /common ou /consumers. Utilisez plutôt /organizations ou un ID de locataire.

Pour en savoir plus

Pour obtenir un exemple d’implémentation du flux ROPC, consultez l’exemple de code application console .NET sur GitHub.