microsoft-authentication-library-for-dotnet: [Bug] AADSTS50196: The server terminated an operation because it encountered a loop while processing a request

Which Version of MSAL are you using ? MSAL 4.12.0

Platform net462

What authentication flow has the issue?

  • Desktop / Mobile
    • Interactive
    • Integrated Windows Auth
    • Username Password
    • Device code flow (browserless)
  • Web App
    • Authorization code
    • OBO
  • Web API
    • OBO

Other? - please describe;

Is this a new or existing app? c. This is a new app or experiment

Repro Each requests from the desktop application to the backend a token is requested. This is happening from multiple threads.

        public IPublicClientApplication App {get;set;}
        ...
        public async Task<AuthenticationResult> AcquireTokenAsync(IAccount account) 
        {
                return await App.AcquireTokenSilent(Scopes, account)
                    .WithAuthority(AadAuthorityAudience.AzureAdAndPersonalMicrosoftAccount)
                    .ExecuteAsync();
        }

Expected behavior I thought that App would cache the tokens and only acquire a new token when it is (nearly) expired?

Actual behavior Exception is thrown. AADSTS50196: The server terminated an operation because it encountered a loop while processing a request

Possible Solution Should I cache the token myself or lock the App instance for single use only?

Additional context/ Logs / Screenshots Seems the Javascript MSAL library had the same issue https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/547

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 17 (8 by maintainers)

Most upvoted comments

@rfcdejong - the error you are getting seems to indicate that the server is throttling you. This can occur if a variety of situations:

  • you call AAD too often with same request
  • AAD is having problems and is asking you to back off (but more likely is the 1st issue)

It may be that your app is retrying the same request too often, maybe there is a bug in your async handling or in some retry policy?

Some thoughts on high availability that might help: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/High-availability

@jmprieur - client side throttling was not released in 4.12, it will be available in 4.13. The server behavior when it detects a loop is to break the loop by sending an “invalid_grant” suberror, which MSALs interpret as “UI Required Exception”. I am not sure if a retry-after header is sent, probably not. At some point, we want the server to send HTTP 429 / Retry-After X messages instead, but discussions are still ongoing. Without this signal, client side throttling will not work. Oh, and for now, client-side throttling will not be enabled on confidential client flows. So probably 4.14 if we decide it’s a good idea?

@ashinzekene - please open a new issue

@nmushovic @TheJoeFin - could you please open new work items and reference this one? Closed items tend to get less attention.

It is possible there is a bug in the library or on the server if the token cache is bypassed by AcquireTokenSilent. This can happen if you request scopes X, Y, Z and the server reports scopes X, Y only.

Could please detail exactly the scopes you request, if you serialize the cache (not required on UWP) and if you follow the pattern

try 
   AcquireTokenSilent
catch UIRequiredException
   AcquireTokenInteractive