Azure-docs: Stating scopes require just the ClientId

[BeMor81]

As well as the double slash rule I have also found despite setting an application URI ID the scope has to be set using just the Client ID so {ClientId}/{Scope} e.g. 00000000-0000-0000-0000-000000000000/user_access and api://00000000-0000-0000-0000-000000000000/user_access doesn't work or what ever the URI maybe set to. I've only found this to be the case on some AAD Application Proxies which were setup sometime ago. I understand this may not be common but it costed me a great deal of time to resolve and find the solution.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 1dc5f32d-7f05-cb8e-fc96-f1a2da4c605f
• Version Independent ID: 79665705-66cc-995f-6b89-7239bbdee2aa
• Content: Acquire & cache tokens with MSAL - Microsoft identity platform
• Content Source: articles/active-directory/develop/msal-acquire-cache-tokens.md
• Service: active-directory
• Sub-service: develop
• GitHub Login: @mmacy
• Microsoft Alias: marsma

[neeleshray-msft]

@BeMor81 Thank you for your feedback . We will investigate and update the thread further.

[BeMor]

Thanks, sorry I should have added, of course this in turns sets the audience to the client ID rather than the URI which seems to be what is needed.

[neeleshray-msft]

@mmacy Could this be added to the document ?

[mmacy]

Hi @BeMor81, it's not clear to me from this part of your statement here which does and does not work for you:

despite setting an application URI ID the scope has to be set using just the Client ID so {ClientId}/{Scope} e.g. 00000000-0000-0000-0000-000000000000/user_access and api://00000000-0000-0000-0000-000000000000/user_access doesn't work**

Can you expand a bit further?

[BeMor]

Hi @BeMor81, it's not clear to me from this part of your statement here which does and does not work for you:

despite setting an application URI ID the scope has to be set using just the Client ID so {ClientId}/{Scope} e.g. 00000000-0000-0000-0000-000000000000/user_access and api://00000000-0000-0000-0000-000000000000/user_access doesn't work**

Can you expand a bit further?

Hi @mmacy,

The audience claim has to be the client Id, the GUID for some of the Azure resource you're trying to access despite having an app ID URI set. In my case this was a AAD Application Proxy which was setup a couple of years ago I believe. It was the note on the double slash for the Azure Resource Manager API which made me realise the issue.

So even if I use the default app ID URI of app://{client id guid}/some_scope or app://{some.domain}/some_scope the resulting audience of app://{client id guid} and app://{some.domain} didn't work.

I found that if I set the scope just to {client id guid}/some_scope , so minus the protocol the resulting audience claim, {client id guid} worked. All of the previous audiences resulted in a 302 redirect to the login URL.

[mmacy]

Thanks for the additional details, @BeMor! I'll do some investigation on this side to see if we can determine why this might be the case for your older app proxies. Will leave this one open for now, thanks for your patience.

[mmacy]

@BeMor  this has to do with how the aud is determined by AAD when parsing the scope in the request, and how it's then passed to the downstream service in the access token. This results in multiple audience values being used for the same resource, and the resource likely has not configured itself to accept all of these variations.

I'll update the article to mention that one should try the URI without the scheme and host if it yields a 401.