microsoft-authentication-library-for-java icon indicating copy to clipboard operation
microsoft-authentication-library-for-java copied to clipboard

Add ROPC flow support to confidential client

Open aszego opened this issue 4 years ago • 15 comments

Azure AD supports ROPC for confidential clients, and thus MSAL4J should support it as well. Even if this flow requires high trust, there're valid use cases like automation.

To illustrate what I mean, here's a simple implementation that extends ConfidentialClientApplication.

aszego avatar Jul 06 '20 15:07 aszego

@aszego Does client credentials flow work for your scenario?

There are no plans to add ROPC to confidential clients, as client credentials flow already meet all of the same use cases.

sangonzal avatar Jul 06 '20 16:07 sangonzal

According to this article, the client credentials flow should support ROPC, as we could see both client secret and username/password are passed to IdP. image Just wonder if the Library could support this flow?

charleshcl avatar Jul 07 '20 03:07 charleshcl

@sangonzal The client credentials flow does not work for us.

In particular, in our automation scenario we are using Exchange Web Services to access Exchange Online. IdP is Azure AD of course. However, EXO does not allow placing constraints on mailbox access for application principals. On the other hand, when delegating permissions of a service account instead, it's possible to constrain access to a set of mailboxes. This should affect many large organizations migrating to Microsoft 365.

@charleshcl That's exactly my point as well.

aszego avatar Jul 07 '20 08:07 aszego

According to this article, the client credentials flow should support ROPC, as we could see both client secret and username/password are passed to IdP. image Just wonder if the Library could support this flow?

Client credential flow is used when client wants to use its own credentials, instead of impersonating a user. So it requests access on behalf of itself, not user

SomkaPe avatar Jul 14 '20 20:07 SomkaPe

According to this article, the client credentials flow should support ROPC, as we could see both client secret and username/password are passed to IdP. image Just wonder if the Library could support this flow?

Client credential flow is used when client wants to use its own credentials, instead of impersonating a user. So it requests access on behalf of itself, not user

My understanding is the username here refers to service account's name. It's not impersonating the user.

charleshcl avatar Jul 15 '20 02:07 charleshcl

In my daemon app I need to send email on behalf of me. I got an advice to use On Behalf of flow involving ROPC as the first step: https://docs.microsoft.com/en-us/answers/questions/43724/sending-emails-from-daemon-app-using-graph-api-on.html Seeing the lack of interest in adding support ROPC to this library how else I should implement that On Behalf flow?

jan-tosovsky-cz avatar Jul 15 '20 12:07 jan-tosovsky-cz

We are discouraging the use of ROPC, and do not currently have a timeline for adding this functionality. While it exists on public client we highly recommend using non ROPC flows.

henrik-me avatar Jul 27 '20 18:07 henrik-me

When I tried ROPC using public client i am getting below error: code snipped: UserNamePasswordParameters userNamePasswordParameters = UserNamePasswordParameters.builder(scopes,email,password.toCharArray()).build(); PublicClientApplication publicClientApplication = PublicClientApplication.builder(clientId) .authority(AUTHORITY).build(); CompletableFuture<IAuthenticationResult> future = publicClientApplication.acquireToken(userNamePasswordParameters);

Error: 16:30:41.219 [ForkJoinPool.commonPool-worker-1] INFO com.microsoft.aad.msal4j.WSTrustResponse - Found token of type: urn:oasis:names:tc:SAML:1.0:assertion 16:30:41.583 [ForkJoinPool.commonPool-worker-1] ERROR com.microsoft.aad.msal4j.PublicClientApplication - [Correlation ID:xxxx] Execution of class com.microsoft.aad.msal4j.AcquireTokenByAuthorizationGrantSupplier failed. com.microsoft.aad.msal4j.MsalInteractionRequiredException: AADSTS53003: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.

@henrik-me .Kindly help.Thanks for your support.

maxynandy avatar Feb 08 '21 08:02 maxynandy

Hello @maxynandy : This thread was for discussing plans for adding extra functionality for ROPC, not really about specific issues.

Please create a separate thread to track and discuss your issue, though judging by the error message I assume it has something to do with the access policies on the app rather than anything specific with the MSAL Java library.

Avery-Dunn avatar Feb 08 '21 21:02 Avery-Dunn

@Avery-Dunn Thanks I have raised new issue:350 and please note same AD configuration works in dot net.

maxynandy avatar Feb 09 '21 01:02 maxynandy

@henrik-me can this issue be closed since we are not planning to add ROPC to confidential clients?

siddhijain avatar Apr 26 '22 02:04 siddhijain

@siddhijain I do not recall if this ended on our consistency item list or not. I don't see it tagged as such here. Please help follow up on that.

henrik-me avatar Apr 26 '22 16:04 henrik-me

MSAL for Python does support ROPC for Confidential Client. Why MSAL for Java doesn't support this?

If we are to use Public Client with ROPC then we would have to enable Public Client Flow in the Azure AD settings. Whereas with Confidential Client enabling Publc Client Flow wouldn't be necessary. Moreover, we are not sure if enabling Public Client Flow would have other undesirable effects on our app.

Could you, possibly, add ROPC support for Confidential Client?

akulyakhtin avatar Jun 25 '23 20:06 akulyakhtin

If Azure AD supports ROPC for Confidential Client, why should not MSAL4J do the same? By some internal policies we use ROPC with the Confidential Client, and we are not able to use this package, unfortunately.

olegbaslak avatar Apr 24 '24 13:04 olegbaslak

Thanks for the feedback @olegbaslak , it is on the roadmap, but cannot give an ETA.

We recommend folks to use Managed Identity (for app tokens) whenever possible.

bgavrilMS avatar Apr 24 '24 14:04 bgavrilMS