AADSTS90002: Tenant authorize not found : Occurs after update pkg from 3.19.8 -> 4.0.0

[iomdesign]

Which Version of ADAL are you using ?
ADAL 4.0.0

Which platform has the issue?

What authentication flow has the issue?

• Desktop / Mobile
  • Interactive
  • Integrated Windows Auth
  • Username Password
  • Device code flow (browserless)
• Web App
  • Authorization code
  • OBO
• Web API
  • OBO

Other? - please describe;
Headless console app - client credentials flow

Repro

    public class OAuthConfiguration : IOAuthConfiguration
    {
        public string ClientId { get; set; }
        public string ClientSecret { get; set; }
        public string Authority { get; set; }
        public string Resource { get; set; }

    }

    public class OAuthProvider : IOAuthProvider
    {

        private readonly AuthenticationContext authContext;
        private AuthenticationResult authResult;
        private readonly OAuthConfiguration config;

...
        public OAuthProvider(
            OAuthConfiguration config,
            AuthenticationContext authContext
        )
        {
            this.authContext = authContext;
            this.config = config;
        }

        public async Task<AuthenticationResult> GetTokenAsync()
        {
            if (IsTokenExpired())
            {
                try
                {
                    var clientCredential = new ClientCredential(config.ClientId, config.ClientSecret);
                    this.authResult = await authContext.AcquireTokenAsync(config.Resource, clientCredential);

                }
                catch (Exception ex)
                {
                    logger.Error(
                        $"AUTH PROVIDER :: Failed to retrieve token :: {ex.message}");
                }
            }
            return this.authResult;
}

Expected behavior
Using ADAL 3.19.8, the same code and credentials successfully returns an AuthenticaionResult containing a valid bearer token .

Actual behavior
Exception thrown

AADSTS90002: Tenant authorize not found. This may happen if there are no active subscriptions for the tenant. Check with your subscription administrator.
Trace ID: 9a1bb16e-0cdf-4dd4-8a4b-a888a2650e00
Correlation ID: 0aefb133-0763-426e-b0c3-4bb373b7a60d
Timestamp: 2018-10-23 09:31:20Z

Possible Solution

Additional context/ Logs / Screenshots
Add any other context about the problem here, such as logs and screebshots. Logging is described at https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/wiki/Logging-in-ADAL.Net

Another application using the same code and credentials but using ADAL 3.19.8 is still wrking as expected.

[jmprieur]

@iomdesign : how do you initialize the AuthContext?
it seems that the authority is not recognized (See AADSTS90002)

can you please share the authority with us?

Also if you revert back to ADAL 3.19.8 does it still work?

[TedPattison]

I am getting the same error after migrating from 3.x to 4.3. It definitely seems like a breaking change when I have read that there should be no breaking changes when migrating from ADAL.NET 3 to 4. This does not seem to be the case.

Here is a little more info. I am authenticating using UserPasswordCredential. Yes, I know that auth with direct user password is frowned upon, but it is required due to the architecture of Power BI embedding. Here is the authorization endpoint I have been using to create the Authentication Context with ADAL.NET 3.x

When I used ADAL.NET 3.x with UserPasswordCredential, I can successfully acquire an access token and the call goes out to Azure AD using this URL.

https://login.windows.net/common/oauth2/authorize

After updating to ADAL.NET version 4.3, the library changes the URL to this and the call fails.

https://login.microsoftonline.com/authorize/oauth2/token

One other thing I noticed is that ADAL.NET 4.3 also adds a new form variable named client_info with a value of 1 which is passed when attempting to acquire an access token.

Can someone on the ADAL.NET team tell me whether this is a bug or this is expected behavior? If I need to use UserPasswordCredential to acquire an access token, should I avoid migrating to 4.3 and stay with 3.19.8?

[jmprieur]

Thanks for the repro @TedPattison. And sorry for the inconvenience. What you experience is not expected.

In order to narrow-down the issue, could you please try to set the authority to "https://login.microsoftonline.com/common" ? instead of "https://login.windows.net/common" when you initialize the application?

Also, given that you are using common, did you do as recommended: https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/wiki/AuthenticationContext-the-connection-to-Azure-AD#case-when-the-authority-is-not-known-in-advance ?

[Jappinen]

We ran into this as well. Switching authority url from https://login.microsoftonline.com/[guid]/oauth2/token to https://login.microsoftonline.com/[guid] fixed this.

It seems to new version somehow manages to mangle to POST target with the "long" url. From Fiddler:

v4.3.0:
POST https://login.microsoftonline.com/authorize/oauth2/token HTTP/1.1

v3.19.8:
POST https://login.microsoftonline.com/[guid]/oauth2/token HTTP/1.1

[iomdesign]

@jmprieur yes reverting to 3.19.8 fixes the issue.

The AuthContext is initialised via DI in a ServiceCollectionsExtension method.

        public static IServiceCollection AddODataClientFactory(this IServiceCollection services)
        {
            services
                .AddSingleton<IOAuthProvider, OAuthProvider>()
                .AddSingleton(provider =>
                    new AuthenticationContext(provider.GetRequiredService<IOptions<OAuthConfiguration>>().Value.Authority, false)
                )
                .AddSingleton(new ODataClientSettings())
                .AddScoped<IApiClient<ODataClient>, SimpleODataApiClient>()
                ;
            return services;
        }

The Authority is in the format https://login.microsoftonline.com/{Guid}/oauth2/authorize

[TedPattison]

Thanks Jean-Marc,
This is what I first used to initialize AuthenticationContext

• https://login.windows.com/common/oauth2/authorize
• https://login.microsoftonline.com/common/oauth2/authorize

Both of these work in ADAL 3.19 but not in 4.3

Then after your suggestion I trimmed of the end of that URL and used this

• https://login.microsoftonline.com/common

This works fine now in 4.3. My problem is solved.

I guess when using UserPasswordCredential, the call goes to the token endpoint and not the authorization endpoint so it now makes sense why that changed is required. The other observation is that ADAL 3.19 is a more forgiving of a bad URL and while 4.3 is not. I am starting to read through the link you gave about using the common endpoint and how it relates to token caching. Great stuff.

Thanks again.

[MarkZuber]

For transparency...

https://login.microsoftonline.com/{Guid}/oauth2/authorize is not a valid authority. So what the code in 4.x is doing is looking at the tail end of the authority uri for what it expects to be the tenant (in this case, it should be {Guid} but only because the authority url should be https://login.microsoftonline.com/{Guid} [note without the oauth2/authorize which is an endpoint and not part of the authority]).

We are discussing internally how we want to resolve/catch this issue to make it clear (e.g. argumentexception if oauth2/authorize or other endpoint info is inside the authority uri) but 4.x is technically correct if sent a properly formatted authority. This explains why the changes folks have made are resolving the issue since it's now a properly formatted authority.

As for the other question on "client_info"=1 this is part of additional cache work to ensure we get the clientinfo structure back which contains information needed for full cache scenarios. It should not impact any of the behavior that you're seeing in this issue, but that's why the fiddler trace is different. This extra query parameter is expected.