What causes AADSTS50196?

Token caching is missing or misconfigured: every call hits the /token endpoint instead of reusing a cached access token until expiry. The app keeps requesting a new token on every API call (per-request acquisition) instead of using AcquireTokenSilent first. An error or 401 response triggers an unconditional retry that immediately requests another token, creating a tight loop. Multiple processes/instances share the same client_id without a shared cache, each independently hammering the token endpoint. A custom HTTP client or gateway dropping the cached token (e.g., stripping auth headers) so the app re-acquires on every call

How do I fix AADSTS50196?

Check your app's token-request rate against Entra ID sign-in logs (Entra admin center → Sign-in logs, filter on the app + error 50196) to confirm the loop and see how often it's calling /token. Switch to MSAL's AcquireTokenSilent / acquireTokenSilent flow and only fall back to AcquireTokenForClient (or interactive) when the silent call fails — never request a new token per API call. Enable a persistent token cache (MSAL serializable cache, distributed cache for web apps, or Power BI Gateway's built-in cache) so restarts and multiple workers don't each loop on /token. Add exponential backoff on 401/expired-token paths and a circuit breaker that stops retrying after N failures, so a downstream error can't drive a token-request storm. If this is a Power BI custom connector, ADF Web activity, or Databricks job calling Graph/Fabric APIs, audit the auth code for retry-on-failure that re-acquires tokens — replace with cached-token reuse plus bounded retry

Low severityauthentication

Power BI Error:
AADSTS50196, Client Authentication Loop

What does this error mean?

Microsoft Entra ID (Azure AD) blocked the app because it issued the same token request too many times in a short window.

Common causes

1Token caching is missing or misconfigured: every call hits the /token endpoint instead of reusing a cached access token until expiry
2The app keeps requesting a new token on every API call (per-request acquisition) instead of using AcquireTokenSilent first
3An error or 401 response triggers an unconditional retry that immediately requests another token, creating a tight loop
4Multiple processes/instances share the same client_id without a shared cache, each independently hammering the token endpoint
5A custom HTTP client or gateway dropping the cached token (e.g., stripping auth headers) so the app re-acquires on every call

How to fix it

1Check your app's token-request rate against Entra ID sign-in logs (Entra admin center → Sign-in logs, filter on the app + error 50196) to confirm the loop and see how often it's calling /token
2Switch to MSAL's AcquireTokenSilent / acquireTokenSilent flow and only fall back to AcquireTokenForClient (or interactive) when the silent call fails — never request a new token per API call
3Enable a persistent token cache (MSAL serializable cache, distributed cache for web apps, or Power BI Gateway's built-in cache) so restarts and multiple workers don't each loop on /token
4Add exponential backoff on 401/expired-token paths and a circuit breaker that stops retrying after N failures, so a downstream error can't drive a token-request storm
5If this is a Power BI custom connector, ADF Web activity, or Databricks job calling Graph/Fabric APIs, audit the auth code for retry-on-failure that re-acquires tokens — replace with cached-token reuse plus bounded retry

Frequently asked questions

What does AADSTS50196 mean?

A client loop has been detected. Check the

How do I fix this error?

Check your application registration, token configuration, and user permissions in the Azure portal. Review Conditional Access policies if the error is policy-related.

Source · learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes#aadsts-error-codes