Inconsistent authority url building betwen .net implementation and python

[cmberryau]

In the context of using the PowerBI API, I've been testing token aquistion in the .NET library, using the following code:

        var result = true;
        var credential = new UserPasswordCredential(username, password);

        var authenticationContext = new AuthenticationContext(_authorityUrl);
        var authenticationResult = await authenticationContext.AcquireTokenAsync(_resourceUrl, clientId, credential);

        if (authenticationResult == null)
        {
            result = false;
        }

I am able to get a token perfectly and interact with the PowerBI API perfectly. Works great!

I've noticed that during these calls in HttpClientWrapper there are 3 requests. GET (auth discovery), GET (something else) and POST(token request).

The final POST is attempting to request at the following URI:
https://login.microsoftonline.com/common/oauth2/token

However, when I try and use the python library with the following snippet:

context = adal.AuthenticationContext(authority=self.authority_url, validate_authority=True)
token = context.acquire_token_with_username_password(
    resource=self.resource_url, client_id=self.client_id,
    username=the_username, password=the_password)

There are only 2 requests. GET(something else), POST(token request). The final POST 404's. The discovery step is missing, and it's performing static discovery.

The final POST is attempting to request at the following URI: https://login.windows.net/common/oauth2/authorize/oauth2/token

I have tried with validate_authority=True and False.

Here are the provided URLs:

authority_url = 'https://login.windows.net/common/oauth2/authorize'

It seems that the urls finally being used for requests are not the same - perhaps its something worth looking at?

[abhidnya13]

Hi @cmberryau,

The ADAL python library expects the authority URL of the format https://login.windows.net/common. It essentially uses this authority URL value to form the URL to the token endpoint. So, when the authority_url value is https://login.windows.net/common/oauth2/authorize as you provided, it ends up forming an invalid URL to the token endpoint making the POST(token request) a 404.

Why this works with ADAL .Net?
The .NET library is more forgiving to the authority URL that is provided because it internally constructs the correct one.

So, this is definitely an enhancement that we can include in the future releases of the python library.

[rayluo]

Thanks @abhidnya13 ! That makes sense. At a hindsight, although all of our samples already construct authority url in the form of "https://login.microsoftonline.com" + "/" + "tenant", our API documentation does not yet give a clear example. That leaves room for misunderstanding, especially when ADAL .Net is forgiving.

I think a low-hanging fruit would be to:

• add a one-liner example "The authority will look like https://login.microsoftonline.com/your_tenant" to the API doc (which will then be picked up by our coming-soon API reference doc)
• (optionally) raise a ValueError exception when we detect more than one / in the given authority's path section. This way, we won't be as forgiving as ADAL .Net, but we will be explicit about what the valid input will look like. And, "Explicit is better than implicit", that is part of the Zen of Python.

Let's work out a PR for this.