Azure AD的Active Directory身份验证例外（AADSTS90027）

Question

I have a native client application which is obtaining an OAuth2 token for Active Directory authorization. It will then use that token to communicate with a secure Web API server where certain areas of the API are secured using the [Authorize] attribute. The server is also registered with Azure AD and can properly authorize requests through AD.

When I try to get the token, I get the following exception on Line 2 of the code below:

Additional information: invalid_request: AADSTS90027: The client '<Client GUID>' and resource ' https://abccompany.com/MyApplication.Server ' identify the same application.

Here is my code which I am running in the native client (just on a button press as a test, for now). Obviously the GUID and company names have been obfuscated.

AuthenticationContext ac = new AuthenticationContext("https://login.windows.net/abccompany.com");
AuthenticationResult ar = ac.AcquireToken("https://abccompany.com/MyApplication.Server", "<Client GUID>", new Uri("https://localhost:44300/secure"), PromptBehavior.Auto);

I made sure the redirect existed in Azure in the application configuration (otherwise there would have been a redirect error instead). What does the error mean?

Answer 1

You seem to be using the clientId of the WebAPI where you need to supply the clientId of the client app. Please register a separate 'Native client application' in Azure AD representing the client app.

The following topic explains the protocol flow and how to register WebAPIs in Azure AD such that users from multiple AD tenants can use that API: http://msdn.microsoft.com/en-us/library/azure/dn499820.aspx#BKMK_Native The following samples should see you through:

• Single tenant WebAPI: https://github.com/AzureADSamples/NativeClient-WindowsStore
• Multi-tenant WebAPI: https://github.com/AzureADSamples/NativeClient-WebAPI-MultiTenant-WindowsStore

Hope this helps.

---

ps: Azure AD doesn't issue a token when the client and resource are the same application. In your case they should indeed be different and resource clientid (issued to a confidential client) should not be used as a public client - however for service to service scenarios, it can be argued that issuing tokens to self should be allowed - this is something we are looking into.