Azure App Registration - 0Auth Authorize Error - AADSTS650051 - Service principal name is already present for the tenant

Question

I'm integrating Outlook events into my software using Azure App Registration with multi-tenant authentication. I'm using an authorization URL structured as follows:

var authUrl = $"https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?" +
              $"&client_id={{clientId}}" +
              $"&response_type=code" +
              $"&redirect_uri={{redirectUri}}" +
              $"&scope={{scopes}}";

When a user who belongs to another organization tries to log in, the following error occurs:

error=invalid_client
error_description=AADSTS650051: Consent action for Application '<App-GUID>' failed due to the following error: The '<App-GUID>' service principal name is already present for the tenant '<Tenant-GUID>'. paramName: ServicePrincipalName, paramValue: '<App-GUID>', objectType: System.String

• Why does this error occur?
• How can I resolve this issue to successfully authenticate users from multiple tenants?

Any help or suggestions would be greatly appreciated. Thanks!

Answer 1

Hello Mert,

Thank you for detailing your issue clearly. Below is a structured solution addressing your OAuth authentication problem with Azure App Registration.

Issue:

When authenticating users from multiple Azure AD tenants with OAuth, the following error appears during initial consent:

AADSTS650051: Consent action for Application '<App-GUID>' failed due to the following error:  
The '<App-GUID>' service principal name is already present for the tenant '<Tenant-GUID>'.

This error typically occurs when performing consent for a multi-tenant Azure AD app, usually at the first consent interaction from a new tenant.

Cause:

The error usually occurs under these conditions:

• The application is registered as a multi-tenant app in Azure AD.

The tenant trying to authorize already has a conflicting service principal (SPN) associated with the same Application ID (clientId).

Occasionally, this can happen due to transient replication or synchronization delays within Azure AD.

Verified Observations:

This issue commonly arises only the first time a new tenant attempts to consent to a multi-tenant app.

If a user retries the consent (e.g., by navigating again to the OAuth URL), consent typically completes successfully on subsequent attempts without further errors.

Removing the consent from Azure AD (Entra) Admin Portal for the affected tenant allows consistent replication of the issue upon initial consent.

This behavior strongly indicates a potential synchronization or replication issue within Azure AD’s backend.

Recommended Solutions & Workarounds:

Solution 1: Implement Retry Logic (Recommended Quick-Fix)

Since the issue resolves itself upon retry, implement simple retry logic in your OAuth authentication flow:

Detect the specific error code: AADSTS650051

Upon encountering this error, automatically redirect the user back to the original OAuth consent URL once again, allowing consent to successfully complete.

Example (pseudo-code logic):

if (response.Contains("AADSTS650051"))
{
    // Redirect back to OAuth URL
    Response.Redirect(authUrl);
}

Solution 2: Check Tenant SPN Manually (Troubleshooting / Prevention)

Verify manually if the SPN already exists in the tenant:

Navigate to the tenant's Azure Portal (Entra Admin Center).

Check under Enterprise Applications if the SPN for your application (matching App-GUID) exists.

If found, you can manually remove this existing SPN and retry the consent process.

Solution 3: Use Admin Consent URL (Recommended Alternative)

Provide tenants with an admin consent URL to pre-consent to the application explicitly. This reduces user consent errors during initial user login:

https://login.microsoftonline.com/{tenant-id}/adminconsent?client_id={client-id}

This allows tenant administrators to proactively grant consent, avoiding this specific error entirely for regular users.

Best Practices & Recommendations:

Implement retry logic as an immediate workaround to maintain a smooth user experience.

Document clearly to tenant admins the recommended admin consent flow to avoid first-time consent issues.

If consistently reproducible, report it to Microsoft Support through Azure Support tickets as a possible backend synchronization issue.

Conclusion:

Your observed issue appears consistent with transient synchronization behavior within Azure AD multi-tenant authentication flows. Implementing retry logic and encouraging admin consent can effectively mitigate this issue. Should this persist regularly, consider reaching out to Microsoft Support for deeper analysis.

I hope this helps clarify the issue and provides actionable solutions. Please let me know if further assistance is needed.

Best regards, Martin