Can't pass client id as scope to AcquireTokenAsync

I want to achieve the same thing as described in this Azure Documentation “Secure an MVC web API”.

That documentation refers to this github repository which contains the code to achieve what the documentation describes. It is using MSAL version 1.0.304142221-alpha.

It acquires an access token for a Web API that has the same application id as the native client via this call:

app.AcquireTokenAsync(new string[]{clientId})

reference line of code

Where clientId is the same client id passed to the constructor of the PublicClientApplication.

I’ve tried to achieve the same thing, but AcquireTokenAsync throws an exception stating API does not accept client id as a user-provided scope. It looks like this change was introduced in https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/pull/337, specifically this commit.

Why can I not specify the client id as the scope, as described in the MS example? I couldn’t find the reason for this change in the first place.

[cjheppell]

it’s not yet supported by the service.

Then why is there official Azure documentation detailing exactly this particular scenario, including code and a reference to this library as the means of achieving it? All the documentation I’ve read calls this out as supported.

Not even the v2 endpoint limitations document states this is unsupported. In fact, it even suggests you can do this:

To see how to build a Web API that accepts tokens from a client that has the same Application ID, see the v2.0 endpoint Web API samples in our Getting Started section.

Could I suggest calling out explicitly in the documentation that the scenario it describes is currently unavailable?

I really appreciate all your help, but it feels this is something that should be made clear upfront. 😞

[cjheppell]

Thanks for the quick reply.

We want to use MSAL because it allows us to use the v2 endpoint - we have a requirement to support both Azure AD accounts and Microsoft accounts so falling back to ADAL (as far as I know) doesn’t meet our needs.

I thought I might be able to achieve the same thing by not passing the client id, but using the api://{client_id}/{scope} format described in this blog post but that didn’t work either.

It’s a bit disappointing to find Microsoft documentation detailing exactly what I want, only to discover this scenario has since been removed from the library.

We have a planed scenario to support it.

Any ideas when this might be available?