Add ROPC flow support to confidential client

[aszego]

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.

[sangonzal]

@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.

[charleshcl]

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. Just wonder if the Library could support this flow?

[aszego]

@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.

[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. 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

[charleshcl]

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. 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.

[jan-tosovsky-cz]

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?

[henrik-me]

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.

[maxynandy]

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 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.

[Avery-Dunn]

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.

[maxynandy]

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

[siddhijain]

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

[henrik-me]

@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.

[akulyakhtin]

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?

[olegbaslak]

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.

[bgavrilMS]

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.