Improve error code AADSTS50000 documentation.

Edit review per CI 3603

Author: przlplx

support/entra/entra-id/app-integration/error-code-aadsts50000-issuing-token-sign-in-service.md

@@ -1,15 +1,15 @@
 ---
 title: Error AADSTS50000 - There was an error issuing a token or an issue with our sign-in service
-description: Provides a solution to the AADSTS50000 error that occurs when you try to sign in to an Azure app using Microsoft Entra ID.
+description: Provides a solution to the AADSTS50000 error that occurs when you try to sign in to an Azure app by using Microsoft Entra ID.
 ms.service: entra-id
 ms.date: 03/12/2025
 ms.author: bachoang
 ms.custom: sap:Issues Signing In to Applications
 ---
 
-# Error AADSTS50000 with issuing a token or an issue with sign-in service
+# Error AADSTS50000 getting a token or signing in to an Azure app
 
-The AADSTS50000 error can occur during the authentication process or token acquisition flow using the token endpoint. Multiple causes can lead to these errors, and this article provides common scenarios and their resolutions.
+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
 
@@ -19,68 +19,68 @@ When a user tries to sign in to an application that's integrated into Microsoft
 
 ## 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 may 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.
+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 the new password can successfully authenticate to Microsoft Entra ID.
+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 commonly occurs in the on-behalf-of (OBO) flow. Certain parameters required for token acquisition may be missing or invalid.
+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 the client ID is valid and other required parameters are configured correctly. For more information, see [Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow](/entra/identity-platform/v2-oauth2-on-behalf-of-flow).
+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](/entra/identity-platform/v2-oauth2-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 3 for cause 3: Verify application consent settings
 
-1. Go to the [Azure portal](https://portal.azure.com), make sure that the client application (Service Principal) exists in the tenant's **Enterprise Applications** page. You can search for the application by App ID.
-2. Verify that the user has the ability to consent to the application. Check user settings in the **Enterprise Applications** page or review relevant policies affecting user consent.
+1. In the [Azure portal](https://portal.azure.com), 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.
+2. 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 may occur if a symmetric signing key is used.
+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 if symmetric key is used in application object
+#### Step 1: Check whether symmetric key is used in application object
 
 1. In the Azure portal, go to the **App Registrations**.
 2. In the **Manage** section,  select **Manifest**.
-3. Check if there is an entry exists in the `keyCredentials` section with `type=Symmetric` and `usage=Sign`.
+3. Check whether an entry exists in the `keyCredentials` section that includes `type=Symmetric` and `usage=Sign`.
 
-    :::image type="content" source="./media/error-code-aadsts50000-issuing-token-sign-in-service/manifest-sample.png" alt-text="Application Manifest Key Credentials" lightbox="/media/error-code-aadsts50000-issuing-token-sign-in-service/manifest-sample.png":::
+    :::image type="content" source="./media/error-code-aadsts50000-issuing-token-sign-in-service/manifest-sample.png" alt-text="Screenshot that shows the Application Manifest Key Credentials code" lightbox="/media/error-code-aadsts50000-issuing-token-sign-in-service/manifest-sample.png":::
 
 Alternatively, use the Microsoft Graph PowerShell cmdlet [Get-MgApplication](/powershell/module/azuread/get-azureadapplicationkeycredential) to retrieve key credentials.
 
-#### Step 2: Check if symmetric key is used in service principal object
+#### Step 2: Check whether symmetric key is used in service principal object
 
 1. If the application is not found in the **App Registrations** page in the Azure portal, browse to the **Enterprise Applications** page.
 2. Locate the application, and then get the **Object ID** of the Service Principal.
-3. Use [Get-MgServicePrincipal](/powershell/module/microsoft.graph.applications/get-mgserviceprincipal?view=graph-powershell-1.0) to retrieve key credentials.
+3. Use [Get-MgServicePrincipal](/powershell/module/microsoft.graph.applications/get-mgserviceprincipal?view=graph-powershell-1.0) to retrieve the key credentials.
 
 #### Step 3: Remove symmetric signing key
 
-If the symmetric key exists, use:
+If the symmetric key exists:
 
-- [Remove-MgApplicationKey](/powershell/module/microsoft.graph.applications/remove-mgapplicationkey) to remove the symmetric key for the app registration.
-- [Remove-MgServicePrincipalKey](/powershell/module/microsoft.graph.applications/remove-mgserviceprincipalkey) to remove the symmetric key for the service principal object.
+- Use [Remove-MgApplicationKey](/powershell/module/microsoft.graph.applications/remove-mgapplicationkey) to remove the symmetric key for the app registration.
+- Use [Remove-MgServicePrincipalKey](/powershell/module/microsoft.graph.applications/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](/graph/application-saml-sso-configure-api?tabs=http%2Cpowershell-script#step-6-configure-a-signing-certificate).
 
 ## Cause 5: No delegated permission exposed in the resource application (web API)
 
-This error can occur in the following scenario:
+This error might occur in the following scenario:
 
-- You have a multitenant resource application registered in tenant A. This application exposes only **Application Permission** type.
-- In a different tenant B, you have a client application registered. In the **API permission** page for this application, you configure the permission for the resource application registered in the other tenant.
-- Then, you use an OAuth 2 delegated grant flow (for instance auth code grant flow) to request an access token for the resource app with the `/.default` for the web API scope.
+- 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 consent to that delegated permission in the client application.
+Configure the resource application to expose the delegated permission, and then consent to that delegated permission in the client application.