Cannot use built-in OAuth2 authentication against Azure AD?

[mikebaz]

Hello! It appears that it's impossible to use the built-in OAuth 2.0 authentication to get a token from Azure AD.

Some testing shows that the token returned from Azure AD has an incorrect "aud" (audience) claim. Normally that claim would be populated based on what's passed in the query string against the access token endpoint - for example:

https://login.microsoftonline.com/{tenant guid}/oauth2/token?resource=https://management.azure.com

as the "Access token URL" while using the "OAuth 2.0", "Client Credentials" grant type. It appears that the query string is being dropped, so the wrong audience (a default) is being assigned.

There's two possible solutions I think, assuming this is an accurate diagnosis of the issue:

1. Ensure the query string given in the URL is not dropped (this is the better option IMHO)
2. Add a UI for adding the query string to the URL somehow

[dpaulino]

I'll look into this soon. Thanks for reporting!

[dpaulino]

@mikebaz I'd like to reproduce this. Do you have a doc somewhere that I can use to set up something similar to what you have in azure and then I'll try to reproduce the issue?

[mikebaz]

Hello @dpaulino , thanks for reaching out about this. Although you can really try any request against the ARM APIs, the specific one I was using was:

https://management.azure.com/subscriptions/subscriptionid/providers/Microsoft.Network/virtualNetworks?api-version=2018-07-01

To have this work, I'm currently using a manual Authorization header with a "Bearer token" value.

For the failing OAuth setup, I created a new app registration in Azure AD, obtained the Client ID and Client secret, and used those with the appropriate token URL:

Does that give you enough info?

[dpaulino]

Hi @mikebaz I was able to successfully get an oauth 2.0 token for azure (See the bottom field called "Access token" is populated)

Here are the steps I took

• Registered a new app in Azure AD
• Created client secret for that new app in Azure AD
• Opened a new tab in Nightingale > navigated to the auth section > switched to oauth2
• Grant type was changed to authorization code
• Following this guide, I added filled in the following fields in Nightingale
  • Authorization URL: https://login.microsoftonline.com/{tenant}/oauth2/authorize
  • client id: {client id}
  • callback url: {the same redirect/response/callback url I supplied in step 1)
• Then, I scrolled down to the access token section. Using this section of the guide, I filled out the following fields in Nightingale
  • Access token URL: https://login.microsoftonline.com/{tenant id}/oauth2/token
  • client secret: {the client secret I created in step 2)
• Then I clicked "Get new token"
• A pop up appeared asking me to log in. After logging in, the access token was returned. (screen shot of pop up below)

Were these the steps you took?

[mikebaz]

I'm embarrassed to admit that I had one the URLs wrong. I actually just now got this working with the 2.0 endpoints (e.g. /oauth2/v2.0/token so I'm good. I think I just needed someone to slap me around a little. :)

Thanks, I'm going to close the issue.

p.s. it's a small gesture but I wanted to show appreciation:

[mikebaz]

actually I reopening because I realize that I think the same issue is still present :( after you get the token, can you examine it in say jwt.io or jwt.ms and see if the aud is being populated from the resource in the query string? it looks like it's back to being dropped?

[dpaulino]

I'll take a look soon, thanks for reopening so I can investigate!

[mderriey]

The AAD v2.0 endpoint, also known as the Microsoft Identity Platform, doesn't use the resource parameter, but the OAuth 2.0 standard scope one, which needs to be passed in the request body.

See https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow#get-a-token.

[dpaulino]

@mderriey thanks for the context. Are you thinking that perhaps this is a bug in nightingale?

[mderriey]

Sorry if my answer wasn't clear. I'm not familiar with how Nightingale performs the OAuth 2.0 token acquisition, but I think passing the scope in the body is more standardised than having a resource parameter passed in the query string.

With the knowledge that I have from the thread, I think it's the normal behaviour that the aud claim in the token doesn't necessarily reflect the resource query string parameter.

My understanding is that the v2.0 endpoints don't use a resource parameter in the first place.

[wjvii]

I ran into this or something similar today as well, our web apis check the audience and what is being passed in when I call it from Nightingale is 00000002-0000-0000-c000-000000000000. My scope does have the audience (api://guid/readaccess) where api://guid is my audience but that is not what the API receives in the access token.

So how can we set the audience? Maybe another parameter we can just enter the audience we want?

I would like to request support for interactive token acquisition, possibly use MSAL and the PublicClientApplicationBuilder, so all we have to supply is the clientid, url and scope and maybe audience and then let us get prompted for credentials. This way we would not have to deal with the client secret and not worry about the security of it.

Thank you.

[wjvii]

OK, I think I have a solution that works fine for me, does not need a client secret and solved the audience issue. The main thing appears to be changing it to the v2.0 endpoints.

Grant type: Authorization code Access token URL: https://login.microsoftonline.com/common/oauth2/v2.0/token Client ID: appguid Client secret: leave blank Callback URL: https://login.microsoftonline.com/common/oauth2/nativecIient Authorization URL: https://login.microsoftonline.com/common/oauth2/v2.0/authorize Scope: api://webapiguid/readaccess

This is still not perfect because it does not deal or at least show the Refresh token and if I click Refresh token it does not work, since it didn't have one to use I am guessing. That said it prompts me when I click Get new token and that token works. Although the Client secret field shows required, it does not appear to need to be when done this way.