[Bug] Fix error message and document throttling (AADSTS50196)

Which version of MSAL.NET are you using? MSAL.NET 4.32

Platform .NET Framework 4.7.2

What authentication flow has the issue?

• Desktop / Mobile
  • Interactive
  • Integrated Windows Authentication
  • Username Password
  • Device code flow (browserless)
• Web app
  • Authorization code
  • On-Behalf-Of
• Daemon app
  • Service to Service calls

Is this a new or existing app? Upgraded from 4.28 (?) to 4.32 when AADSTS50196 started to appear.

Repro

• Create one cache per “client” (app concept) per feature test
  • Note: because all tests do that, this effectively makes the cache miss all the time since it’s recreated for all tests and all clients trying to authn
• Run test with 2+ clients, all using the same user account
  • This will result in 2+ authn queries being raised almost at the same time, for the same AAD account
• For each client, call AcquireTokenSilent() (with the same account), which always fails with MsalUiRequiredException since the cache is brand new and not shared among test clients
• Call AcquireTokenInteractive() on exception caught

Expected behavior All clients (which use the same AAD account) login successfully.

Actual behavior AADSTS50196: The server terminated an operation because it encountered a loop while processing a request Problems are:

• Error message is wrong; the code has no loop
• This error is an MsalUiRequiredException exception, which is not documented with AcquireTokenInteractive()
• #1788 hinted us that this was maybe throttling; this behavior is not documented AFAIK, and the exception type name doesn’t match. Probably there should be a different exception, because unlike MsalUiRequiredException the end-user here cannot do anything about this issue, this is an error of the app code itself
• We didn’t find any mention of throttling in release notes of 4.28+ => 4.32, nor what the throttling duration was

Possible solution We’re investigating sharing the token cache more broadly in tests to avoid multiple calls to the authn server in a short period (that is, to effectively leverage the cache and therefore have at worst one authn per test, and at best one per test run). TBD for results on whether that works.

Additional context / logs / screenshots To be clear, we understand that if the bug is indeed throttling then this is an error on our side, misusing the API. But we found no way to confirm that, which is the actual bug being logged here.

[djee-ms]

That looks good, thanks for the update @bgavrilMS. I still think a separate exception would make more sense, though I get that this is one that would only be seen during development (before you fix the app to use the proper flow) so that’s a bit awkward. Thanks.

[bgavrilMS]

@djee-ms - I updated the wiki page with details on how AAD throttles applications and how to setup token caching. We’re not expecting apps to handle this exception - the app needs to make proper use of cache. I hope the new wiki page makes this clearer:

https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Client-Throttling