Correct password grant request gets throttled following an incorrect one

[akulyakhtin]

The scenario is as follows:

1. Client uses MSAL to obtain an access token using ROPC public flow. It passes a correct username and an incorrect password.

2. Because the client is federated, MSAL eventually calls WSTrustRequest.execute(), passing username/password.

3. WSTrustRequest.execute() makes a SOAP request call to our server. It uses HttpHelper to send the request. The server sees an incorrect password and responds with HTTP response 500. (This might be an incorrect action on the server side but the issue concerns MSAL and not the server)

4. MSAL in HttpHelper.processThrottlingInstructions() sees response 500, creates request thumbprint and stores the thumbptint in ThrottlingCache and indicates that a request with the same thumbprint can only be performed after ThrottlingCache.DEFAULT_THROTTLING_TIME which is 120 sec.

5. Immediately after that the client issues another ROPC request, this time with the correct password.

6. This new ROPC request also results in the call to WSTrustRequest.execute() and MSAL then wants to make a call to the server using HttpHelper.

7. However, HttpServer.checkForThrottling() sees that the thumbprint of the new request is the same as that of the previous request made by WSTrustRequest.execute() (because urls are the same) and throws MsalThrottlingException and the correct request does not get sent.

We think it's a bug because in this scenario an earlier incorrect request prevents a successful execution of a later correct request .

[bgavrilMS]

Great analysis of the issue.

Indeed MSAL Java will throttle similar requests if the server responds with HTTP 5xx instead of the expected HTTP 4xx which denotes an invalid request.

We will not fix this. ROPC should not be used except in test scenarios, in which case you store the password in a vault and it's never wrong.

[manuelschwarze]

Could it be considered to workaround the described issue by allowing the application that uses MSAL to configure the default threshold value to be used when a server returns a 500er response? This is making the MSAL library unusable for the moment, unless we have our own fork and personal version, which I would really not like to do. I am not really sure what the library logic is trying to solve by having a fixed default for this situation. It cannot really be security driven, because if I am acting as a hacker, I just download the library, set the default threshold to 1 ms and are happy with hacking the system. What else is the reasoning behind it?
BTW, I disagree with what you are saying about ROPC, @bgavrilMS. The testing scenario is only one of the scenarios, there are other scenarios in real life that are requiring ROPC until everything of the application landscape of a company has been fully migrated to use Azure AD OAuth, and this will take years and will not happen over night.

[bgavrilMS]

The threshold there is trying to stop clients who set aggressive retry policies from making calls to the server when the server replies with "I am busy" or "I am having problems", i.e. 5xx error codes. We can decrease that threshold, maybe to several seconds.

Can you elaborate on some scenarios for using ROPC ? We are putting a lot of effort into interactive based authentication, such as ensuring device ID gets injected into the session, conditional access policies etc. In fact dropping support for ROPC entirely is a frequent topic.

Ideally you'd fix your ADFS server to reply with 4xx in this case. Or create a PR with a fix.

[manuelschwarze]

I totally agree: Fixing the ADFS server is first priority, but it is out of our control when and if it will happen. I would be in favor of your suggested solution to reduce the default to a few seconds instead of 2 minutes. Making it somehow configurable is still the most flexible option in my opinion.
You asked about ROPC scenarios: Imagine a larger enterprise with systems that are able to perform work for a user in many different scenarios (incl. unattended processing). Such a system - let's call it System A - takes in the "old world" the user credentials, saves them secured and uses them on behalf of the user, e.g. when the user scheduled some automated process on such a system. System A is calling into other systems, web services, databases using sometimes security tokens derived from the user's credentials, but sometimes also the plain credentials of the user. Let's call them System B, System C and System D. Now, imagine we want to change the landscape to Azure AD OAuth. For a large organization this cannot happen as a big bang approach, but needs to happen step by step. Just think of it not as 4 systems, but hundreds. At the very end, every system (in theory) could integrate Azure AD OAuth without using any username and password anymore. But on the way to this goal, it will still be necessary to collect username and password by System A as long as there is one system it has a dependency on that requires it. Some systems are vendor applications, where the enterprise does not have full control about the road-map - again a reason for delays on the way to be perfect. For this purpose ROPC is the (only reasonable and working) temporary solution in my opinion. So, while I am completely understanding Microsofts efforts to work towards ROPC alternatives, it is important that people who are working on cutting edge do not drift into a dream world, but always also consider real-life scenarios and challenges and migration paths.

[bgavrilMS]

Thanks for explaining the scenario @manuelschwarze

Adding public API for this might more flexible, but it also adds maintenance costs and developer fatigue. I mean you know what this does because you spent a long time looking at MSAL Java code, but a new developer looking into all the MSAL config options would quickly become overwhelmed.

Thinking about this some, I may have a better solution to your problem. All MSAL libraries, including MSAL Java, have extensibility for their HttpClient. This should allow you to monitor traffic and to change the HTTP status from 500 to 400 at the app / MSAL level. No changes in MSAL4J needed, this extensibility point exists today.

See https://learn.microsoft.com/en-us/entra/msal/java/advanced/configure-http-client