API calls for ROPC flow returning wrong response

[cosmicboy79]

I developed a backend Python MSAL client (version 1.30.0) that uses the ROPC flow in a similar way as exemplified in the sample provided in Microsoft guide, i.e., I am using the acquire_token_by_username_password operation.

My use case is that I have to verify the validity of the users credentials, sequentially, in Azure B2C, by using this operation. This works just fine in most of the cases, but in situations when a high number of requests is sent to my Python client, some of the calls to acquire_token_by_username_password return AADB2C90225 (invalid username/password) as response, even though the credentials are actually correct.

I'd like to understand why this happens, as I said, sometimes. Is there, for example, any limitations on the number of calls to acquire_token_by_username_password that can be done? I could not find this information anywhere.

[rayluo]

If you suspect that your app is sending too many requests and your token request is being throttled, do not JUST use most other acquire_token_by_blah_blah() method. Utilize acquire_token_silent() method whenever possible. Have you fully followed the pattern which was shown in our sample/docs above?

[cosmicboy79]

Thanks for interacting in this issue.

As I see it, the use case I have demands the usage of acquire_token_by_username_password because the backend Python MSAL client must receive a set of usernames and passwords as input, and validate each pair of them in Azure B2C. I don't see that silently acquiring a token by username only is an option in this case.

The developer has implemented a rate limit in the application (3 seconds delay) to avoid sending too many requests, one after the other, right away. However, for some cases the application receives back “invalid credentials” as response, even though the credentials are valid (if we check them, manually).

The reason I posted this issue/question was to know any limitations on this API. We could not find any reference specifically about this, and this situation comes as unexpected.

[cosmicboy79]

This is the pattern the application is currently using:

    clientApp = msal.ConfidentialClientApplication(
        CLIENT_ID, authority=AUTHORITY, client_credential=CLIENT_SECRET, token_cache=None
    )

    response = app.acquire_token_by_username_password(
        username=username, password=password, scopes=SCOPE
    )

The application uses this pattern for each username/password received. A client (clientApp object) is created for each request, in order to avoid caching issues.

We have observed that when the application is executed many times due to a large set of usernames/passwords, sometimes response is "invalid credentials", for credentials that are actually valid, if verified manually.

[rayluo]

Your usage pattern consists of:

• clientApp = msal.ConfidentialClientApplication(..., token_cache=None)
• avoiding acquire_token_silent(...)
• "A client (clientApp object) is created for each request, in order to avoid caching issues" [sic]

Each of them means you explicitly turn off the token cache. That is NOT the pattern you see in the doc you quoted (which is derived from this runnable sample). That sample demonstrates how ROPC flow can still benefit from using token cache, via acquire_token_silent(...).

You did not elaborate why you did it your way "in order to avoid caching issues". Half of the value of using MSAL library is that it handles token caching for you. If you suspect your usage pattern ran into throttling issue now, you shall really reconsider your approach to token cache.

In any case, our troubleshooting generally requires using our out-of-the-box sample to reproduce an issue. Please let us know if you still run into the same issue after you use our exact sample (which utilizes token cache); if so, please provide the error response.

[cosmicboy79]

Hello,

Thanks, again, for taking the time to reply, but I am afraid the use case I shared was not correctly understood. I apologize for any misunderstandings from my part.

Our application is used by a security team that must validate a set of usernames and passwords, together, against Azure B2C; it must be checked whether they are valid or not, and for that, the application calls acquire_token_by_username_password, directly, simply because this is the only method found by the developers in the MSAL API that authenticates with both username and password against Azure B2C.

That is why we understand that using Token Cache and acquiring a token silently, as show in the sample, does not help: we do not want to have a token cache or getting a token without the password. We simply want to use an authentication method that demands both username and password, so that the security team can know whether they are valid or not.

The application exposes a REST API that receives username+password, which is used in the code I shared earlier:

    clientApp = msal.ConfidentialClientApplication(
        CLIENT_ID, authority=AUTHORITY, client_credential=CLIENT_SECRET, token_cache=None
    )

    response = app.acquire_token_by_username_password(
        username=username, password=password, scopes=SCOPE
    )

As I mentioned, a rate limit control was implemented to avoid calling this code right away (delay up to 3 seconds) per each REST call. As I also mentioned, for a big set of usernames/passwords, sometimes acquire_token_by_username_password returns AADB2C90225, which means that the passed credentials are invalid. However, if we check manually (by logging at another online application that uses Azure B2C) they are indeed valid.

We would like to understand why does acquire_token_by_username_password sometimes return AADB2C90225 for valid credentials. This is misleading behavior.

We've even heard that Microsoft has an internal queue somewhere, and this method is only able to process a batch of 20 requests at a given time, or something like that. We could not find any official information on this, though. That's why we decided to ask here.

[rayluo]

Understood. So, your application (1) gets a hold of "a set of usernames and their passwords"; and (2) your app is not the logical owner (such as the user info database which is the single source of truth) of those passwords (otherwise you won't need to periodically probe those passwords). That is a unique pattern, to say the least.

Even if you kind of justify your usage pattern, there is still not much this library can do here. The library just surfaces the underlying error to the caller. You may consider asking your throttling limit question in Stackoverflow, and/or adjust your probing frequence.

Last but not least, Microsoft Entra ID - and perhaps the entire industry - is moving away from username password. Not sure how much longer your ROPC-based usage can sustain.

[cosmicboy79]

I agree about this moving away from username password: I can notice it already, as a normal user of many other systems and applications in my daily life. I also think it is a good thing, because it doesn't matter how strong we try to create our passwords, they remain a vulnerability. However, as long as our partners rely on this authentication method, we need to maintain it...

We will try to search for more information on StackOverflow, as suggested, but we are also considering to search for official support from Microsoft on this issue.

Thanks again for your input.