This post going to be a live document for the Azure AD sign in related errors (AADSTSXXXXXX) and my experience troubleshooting them by using official documentation and 3rd parties’ blogs.
For the SAML SSO applications make sure to use build in SAML sign in test option to test SSO before putting the application into production.
Also you can use the Microsoft Azure AD error portal to get additional information about the error – https://login.microsoftonline.com/error
And of course would recommend the blog from my friends in Azure AD Dev support team that contains a lot of excellent articles related to Consent, Graph, MSAL/ADAL and Azure AD applications errors.
AADSTS error codes
AADSTS50008: Unable to verify token signature. The signing key identifier does not match any valid registered keys – see the following post in my blog;
AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application: ‘IAMShowcase’ – the error description is self-explanatory. I would highly recommend using the Test option when configuring SAML SSO. As you can see on the screenshot, the wizard allows you to put the error message along with timestamp and correlationID and gives you potential fix or links to documentation;
AADSTS501461: AcceptMappedClaims is only supported for a token audience matching the application GUID or an audience within the tenant’s verified domains. Either change the resource identifier, or use an application-specific signing key – even though official documentation is stating that a custom signing key must be assigned to the SPN object for a claims mapping policy to take effect, many threads online say this is not a requirement any more and the first thing to check for you is the identifierUris attribute in the resource app Manifest to contain the verified domain. Some good tips on the usage of Claims Mapping Policy can be found here;
AADSTS65001, AADSTS650056, AADSTS90008 – see Azure AD Dev support team blog for the possible solution;
AADSTS75011: Authentication method ‘X509, MultiFactor’ by which the user authenticated with the service doesn’t match requested authentication method ‘Password, ProtectedTransport’. Contact the Lever application owner – Usually this is caused by the fact that the SAML application is specifying the RequestedAuthContext with the Comparison attribute set to “exact” in SAML request sent to Azure AD.
Something like this: Comparison=”exact”><saml:AuthnContextClassRef xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion”>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></samlp:RequestedAuthnContext></samlp:AuthnRequest>
And at the same time the user already has signed in with Azure AD using “X509, Multifactor” method – certificate + MFA.
Little bit more info about supported SAML auth context classes here.
The recommended solution is to ask the app vendor to remove this optional SAML parameter;
AADSTS750054: SAMLRequest or SAMLResponse must be present as query string parameters in HTTP request for SAML Redirect binding – per my experience this error might happen when the application that support IdP initiated sign in flow only is set up for SP initiated sign flow by configuring “Sign on URL” in app settings on Azure AD side. Or the URL configured in the “Sign on URL” is not expecting to get any redirections from IdP and redirecting back to Azure AD with no SAML Request. Also see official document;
AADSTS90015: Requested query string is too long – using fiddler you can check the SAML Request query sting size. It should not exceed 4096 bytes. Also make sure the SAML Request is not signed, since Azure AD doesn’t support it. Work with the application vendor to address both.
This error can also be seen for OAuth flow (have seen it for Databricks auth flow). Check the query parameters like state to see if the hash value was included and its too big. Work with the application support team to get this addressed;
AADSTS90094: Administrator consent is required. The actual message content is runtime specific. Please see returned exception message for details – the error reason is described here and here. Another scenario when this error might occur is when the user assignment is required for the application and no Administrator Consent was provided at that moment. In this case Administrator must provide the Administrator Consent first.