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.
First I would recommend reading the message in the error and then searching for the error description in this official documentationand this one.
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 SP 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;
AADSTS54008: Multi-Factor authentication is required and the credential used (Sms) is not supported as a First Factor – In case you have enabled SMS based authentication and the user who signs in with the SMS falls under Azure AD Conditional access policy that requires MFA, this is expected error due to mentioned limitation;
AADSTS700016: Application with identifier ‘IAMShowcase’ was not found in the directory ’59c7e3d5-8501-42b8-9957-ba86e9f49882′. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant – The error is indication that the Identifier (EntityID) mentioned in the request for the token to Azure AD is not set up for any application.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 and allows you to fix it right from the wizard (“Fix It” button)!
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.
AADSTS50000: There was an error issuing a token or an issue with our sign-in service. – in case you are experiencing it with AWS SSO app or when using the claims regex transformation feature, see this post for potential fix.
- Azure AD
- Sign In Troubleshooting
