Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
The AADSTS50000 error can occur during the authentication process or token acquisition flow that uses the token endpoint. These errors can have multiple causes. This article provides common scenarios and resolutions for this error.
Symptoms
When a user tries to sign in to an application that's integrated into Microsoft Entra ID, the user receives the following error message:
AADSTS50000: There was an error issuing a token or an issue with our sign-in service.
Cause 1: The user password is expired, invalid, or out of sync
This issue is common in hybrid environments. The user's federated account password might be out of sync between the on-premises Active Directory and Microsoft Entra ID. Additionally, this issue can also occur when a user session is being revoked.
Solution for cause 1
Reset the user password, and then verify that the new password can successfully authenticate to Microsoft Entra ID.
Cause 2: Parameters are incorrectly configured in the token acquisition request
This problem commonly occurs in the on-behalf-of (OBO) flow. Certain parameters that are required for token acquisition might be missing or invalid.
Solution for cause 2
Make sure that the client ID is valid and that other required parameters are configured correctly. For more information, see Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow.
Cause 3: Consent-related issues
This issue can occur in an OAuth2 Device code grant flow to the token endpoint. After the user signs in to a browser window and accepts the consent dialog, this error occurs.
Solution for cause 3: Verify application consent settings
- In the Azure portal, make sure that the client application (Service Principal) exists on the tenant's Enterprise Applications page. You can search for the application by App ID.
- Verify that the user can consent to the application. Check the user settings on the Enterprise Applications page or review relevant policies that affect user consent.
Cause 4: Symmetric signing key is used in the application or service principal object
Microsoft Identity Platform (v2 endpoint) tokens must be signed by a certificate (asymmetric key). Errors might occur if a symmetric signing key is used.
Solution for cause 4
Step 1: Check whether symmetric key is used in application object
In the Azure portal, go to the App Registrations.
In the Manage section, select Manifest.
Check whether an entry exists in the
keyCredentials
section that includestype=Symmetric
andusage=Sign
.
Alternatively, use the Microsoft Graph PowerShell cmdlet Get-MgApplication to retrieve key credentials.
Step 2: Check whether symmetric key is used in service principal object
- If the application is not found in the App Registrations page in the Azure portal, browse to the Enterprise Applications page.
- Locate the application, and then get the Object ID of the Service Principal.
- Use Get-MgServicePrincipal to retrieve the key credentials.
Step 3: Remove symmetric signing key
If the symmetric key exists:
- Use Remove-MgApplicationKey to remove the symmetric key for the app registration.
- Use Remove-MgServicePrincipalKey to remove the symmetric key for the service principal object.
If a signing key is required, use a signing certificate instead. For more information, see SAML-based single sign-on: Configure a signing certificate.
Cause 5: No delegated permission exposed in the resource application (web API)
This error might occur in the following scenario:
- You have a multitenant resource application that's registered in Tenant A. This application exposes only the Application Permission type.
- In Tenant B, you have a client application registered. In the API permission page for this application, you configure the permission for the resource application that's registered in Tenant A.
- You use an OAuth 2 delegated grant flow (for instance auth code grant flow) to request an access token for the resource app that uses
/.default
as the value of the web API scope.
Solution for cause 5
Configure the resource application to expose the delegated permission, and then consent to that delegated permission in the client application.