J'ai essayé d'acquérir un jeton en utilisant ROPC avec le nom d'utilisateur et le mot de passe fournis par le client. Mais le message d'erreur était "parsing_wstrust_response_failed". Identique au message d'erreur (dernière erreur) décrit ici
D'après ce message d'erreur, j'ai compris que mon utilisateur est un utilisateur fédéré et ne peut pas utiliser cette méthode. Existe-t-il un autre moyen d'acquérir un jeton pour un utilisateur fédéré à l'aide d'un nom d'utilisateur et d'un mot de passe?
try
{
result = await app.AcquireTokenByUsernamePassword(scopes,
"joe@contoso.com",
securePassword)
.ExecuteAsync();
}
catch (MsalClientException ex) when (ex.ErrorCode=="parsing_wstrust_response_failed"){
}
3 Réponses :
Non. Il n'y a pas moyen. Vous devez gérer l'authentification avec un autre flux.
J'ai mentionné cet inconvénient dans mon article récent: https: // joonasw.net/view/ropc-grant-flow-in-azure-ad
Si l'IdP fédéré le prend en charge, cette méthode MSAL peut être utilisée (bien que ce ne soit pas ROPC, c'est WS-Trust avec un nom d'utilisateur / mot de passe contre l'IdP fédéré et un échange de jetons avec Azure AD).
Merci Philippe :) Je ne savais pas qu'AAD ferait ça dans les coulisses. Cela ne veut toujours pas dire que vous devriez utiliser ROPC: P
MSAL fait (la bibliothèque côté client), pas Azure AD. Mais totalement d’accord avec vous, quel que soit le protocole, c’est une mauvaise idée. :)
Tout d'abord, un avertissement: vous ne devez vraiment pas utiliser de nom d'utilisateur / mot de passe dans votre application. En général, il est moins sécurisé et augmente le risque auquel vous exposez l'environnement associé. C'est également une approche fragile, car vous constaterez probablement qu'Azure AD nécessitera une connexion interactive à un moment donné dans le futur - probablement à un moment très gênant pour vous.
Deuxièmement, une clarification: AcquireTokenByUsernamePassword n'utilisera pas toujours le flux OAuth 2.0 des informations d'identification du mot de passe du propriétaire de la ressource (ROPC). Lorsque MSAL découvre que l'utilisateur fait partie d'un nom de domaine fédéré, la bibliothèque tentera une authentification non interactive par nom d'utilisateur / mot de passe si le fournisseur d'identité fédérée publie un document d'échange de métadonnées qui inclut un point de terminaison prenant en charge cette méthode . Si cette demande aboutit, MSAL tentera alors d'échanger la réponse (émise par le fournisseur d'identité fédérée) contre l'ensemble de jetons normal d'Azure AD (émis par Azure AD).
Donc, pour répondre à votre question: cela dépend. Il est possible d'utiliser AcquireTokenByUsernamePassword avec un utilisateur fédéré. Cependant, cela nécessite que le service d'identité fédérée le prenne en charge. AD FS, qui est l'IdP le plus courant à fédérer avec Azure AD, prend en charge ce point de terminaison" usernamemixed ".
En fonction de ce que vous essayez de construire, vous pouvez utiliser AcquireTokenByIntegratedWindowsAuth () à la place. Notre scénario était que nous avions besoin d'une application de console sans tête pour pouvoir envoyer des e-mails et des notifications à un canal Teams. Nous sommes également fédérés, donc l'authentification par nom d'utilisateur \ mot de passe ne fonctionnera pas. Mais comme nous fonctionnons sous Windows, nous pouvons utiliser l'authentification intégrée.
J'ai suivi ce guide pour obtenir le jeton d'accès: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Integrated-Windows-Authentication
Notre scénario nécessitait un consentement unique de l'utilisateur, de sorte que l'utilisateur de l'application console s'exécute avec les autorisations appropriées. https://login.microsoftonline.com/ {tenantId} /oauth2/v2.0/authorize?client_id = {clientId} & response_type = code & scope = {scopes}