AAD AcquireToken returns error AADSTS50000

Question

We use Azure Active Directory to secure our Azure hosted APIs. These APIs are consumed by Azure hosted Angular applications. Mocst of the APIs are implemented as an ASP.NET WebAPI, some of them are now implemented using Azure Functions.

We've been securing our applications this way for the past couple of years and haven't had any issues. We were already granting access to one application based on tokens for the other by adding them to the allowed audiences, which was working fine. Currently, we're running into an issue while implementing a new scenario.

The issue
We have two applications: the current application (cur) and the targeted application (tar). All of our users can login to cur. The backend for cur gets a token to access tar based on the token the user got for cur. This works for users that are backed by an Azure Active Directory, either ours or a federated one. As soon as users log in that are not backed by an Azure Active Directory (which means they are backed by a Microsoft account), getting the token for tar fails with a AADSTS50000: There was an error issuing a token.

Context
Our applications are hosted in a different AAD tenant than where our users and applications are registered. The users and app registrations are in the same AAD tenant. We don't think this is an issue, since the configuration is working for AAD backed accounts.

We're using AuthenticationContext.AcquireTokenAsync(String, ClientCredential, UserAssertion) to get a token to access tar with the following parameters:

ID of tar application
ID and Key of cur
Token of the current user for cur

We're seeing one major difference between the original tokens for AAD backed accounts and Microsoft account backed accounts: the IDP (IdentityProvider) field is different. For Microsoft account backed accounts, the IDP is live.com. For AAD backed accounts, this is https://sts.windows.net/<guid>.

We've created several test accounts, both in our AAD and external ones, to make sure it's not an issue related to our existing user accounts. Using different configurations for our AuthenticationContext or ClientCredential does not solve the issue.

Any ideas?

Asking the obvious question: Are all the NON-AAD backed users imported into both AAD tenants? — Mötz
Thanks @Mötz, I just checked and I worded it wrong: the users and app registrations are in the same AAD, the applications are hosted in a different one. — rickvdbosch
Correct me if I'm wrong. You have Tenant1 and Tenant2. Tenant1 hosts your CUR and TAR applications. Tenant2 contains all your users and Application Registrations. Users created directly as AAD users in Tenant2 works like expected, with the correct configuration. Your NON-AAD users are imported as guests into Tenant2. Is that correctly understood? — Mötz
Although the initial question did imply that, this is not the scenario. I also updated the question a bit to make it more clear: the app registrations and users are defined in Tenant 1, the applications are hosted in Tenant 2. Both AAD backed and external users are in Tenant 1. — rickvdbosch
I wouldn't expect external users (live.com / etc) users that are imported to Tenant1 to be able to access anything in Tenant2 without explicit being imported into Tenant2. They don't live inside Tenant1, they are just guest to that tenant. Can you try and see if importing a external user to Tenant2 makes a difference? — Mötz

Kalyan Krishna Kalyan Krishna · Accepted Answer · 2019-01-10T02:37:40

Inviting users as guest will work, but if thats not a practical option, you'd need to add support for MSA accounts in your apps/services. This is possible via the Azure AD v2.0 endpoint.

The document Comparing the Azure AD v2.0 endpoint with the v1.0 endpoint has a lot of details that you'd need to learn before you start making the changes.

Try out a few of the samples available at Azure Active Directory code samples (v2.0 endpoint) to gain a good understanding.

A short summary of changes that you'd be making

Use the newer MSAL library instead of ADAL.
Use scopes instead of resource
Use the new App registration (Preview) portal.
Update your app registrations to support both AAD and MSA accounts. See signInAudience in Azure Active Directory app manifest.

AAD AcquireToken returns error AADSTS50000

1 Answers