AADSTS90015 fix: sign-in request URL is too long

What does AADSTS90015 mean?

Microsoft’s description:

QueryStringTooLong: The query string is too long.

The message users see is “AADSTS90015: Requested query string is too long.”

Sign-in requests to Entra ID are URLs. An OAuth 2.0 or OpenID Connect sign-in is a request to the /authorize endpoint with everything in the query string: client_id, redirect_uri, scope, state and more. A SAML sign-in works the same way: Microsoft’s SAML reference says the app “uses an HTTP Redirect binding to pass an AuthnRequest” to Entra ID. If that URL gets too long, Entra ID rejects the request with 90015.

Microsoft doesn’t publish the limit. Atlassian’s support article says Microsoft restricts query parameters “to a maximum of 2048 characters”; we haven’t found that number in Microsoft’s documentation.

What makes a request long, in our reading:

• The state parameter. Microsoft says it “can be a string of any content that you wish” and “can also encode information about the user’s state in the app”. Apps that pack a lot into it make every sign-in URL longer.
• Long return or deep-link URLs, carried inside redirect_uri, state or a SAML RelayState, and URL-encoded on top.
• Chained identity providers. Each hop can wrap the previous request in its own. A user on the Okta forum reports the error only with Okta → Okta → Entra ID; single-hop setups worked.

Is it an attack?

No. It is a request Entra ID couldn’t accept, not a failed credential check, and no token is issued. Users report it in these settings:

Pattern	Likely meaning
Many users of one SaaS app at once, starting on the same day	A change on the app vendor’s side. In March 2026 Azure Databricks users in several tenants reported it; a Microsoft Q&A moderator called it a service-side issue, and Databricks fixed it on its side.
One add-on or app, mostly when the user isn’t signed in to it yet	The app’s own sign-in flow builds a long URL. Atlassian documents this for Jira Cloud for Outlook.
SAML through more than one identity provider	Chained redirects. Reported with Okta in front of Entra ID.
One user, intermittently	Our interpretation: a bookmark or deep link with a long return URL. Try the app’s normal start page.

How do I find it in my logs (KQL)?

Microsoft doesn’t document whether a 90015 is written to the sign-in logs. The request is rejected early, and we don’t know whether a row is created. Check all three tables:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "90015"
| summarize Rows = count(), Users = dcount(UserPrincipalName) by SourceTable

If rows exist, find the app, the protocol and the browser. AuthenticationProtocol tells SAML (saml20) from OAuth (oAuth2):

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "90015"
| summarize Rows = count(), Users = dcount(UserPrincipalName),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            UserAgents = make_set(UserAgent, 5)
          by AppDisplayName, AppId, AuthenticationProtocol
| sort by Users desc

Sudden spread across users of one app, the vendor-side pattern. Five users in an hour is a starting point:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == "90015"
| summarize Users = dcount(UserPrincipalName) by AppDisplayName, bin(TimeGenerated, 1h)
| where Users >= 5
| sort by TimeGenerated desc

If the first query returns nothing while users do see the error, the request probably never produced a sign-in row. Then the browser is your only evidence: ask the user for the Request ID, Correlation ID and timestamp from the error page.

How do I fix AADSTS90015?

For the user:

1. Open the app from its normal start address, not from an old bookmark or a link deep inside the app.
2. Clear cookies for the site, or use a private window, and keep only one account signed in. These are the steps suggested to Databricks users while the vendor fix was pending.
3. Jira Cloud for Outlook: Atlassian’s fix is to sign in to id.atlassian.com with Microsoft first, then connect the add-on from Outlook on the web, and then go back to the desktop app.
4. If it still fails, report it with the Request ID, Correlation ID and timestamp from the error page.

For developers:

1. Keep state short. Microsoft: “do not put URLs or other sensitive data directly in the state parameter. Instead, use a key or identifier that corresponds to data stored in browser storage”.
2. Don’t carry long deep-link URLs through the sign-in. Store the target and pass a short key.
3. Request only the scopes you need at sign-in. Every scope adds to the URL.
4. For chained identity providers, cut a hop if you can. Our reading is that each hop adds its own wrapped request.

For admins:

1. Many users of one app at the same time points to the vendor. Check their status page or support before changing anything in your tenant.
2. For a home-built app, send the second query’s result to the developer with the steps above.