Microsoft-authentication-library-for-dotnet: Can't pass client id as scope to AcquireTokenAsync

[cjheppell]

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:

c# 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.

[jmprieur]

Hello @cjheppell : this is currently not possible with MSAL.Net because Azure AD itself does not support it yet. We have a planed scenario to support it.
Meanwhile, I would recommend that you rather use ADAL.Net to secrure a Web API. for instance this sample active-directory-dotnet-webapi-onbehalfof shows how to protect a Web API (it shows a bit more as it also shows how this web APi can call another service)
HTH

[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?

[jmprieur]

I understand your frustration. This has not been removed from the library, BTW, it's not yet supported by the service. this currently only works for JavaScript single page applications (calling the same application Id, which can be an ASP.NET Web API): cc: @aashiman

[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. 😞

[timdunne]

I just spent all afternoon with same issue. The older version of the library referenced in the project mentioned above does allow using the client id. Newer versions of the library complain if you don't use anything other than the Microsoft graph scopes.

[aloene]

Three months later... Any (good) news on this. Is this scenario supported ?

[mcus01]

Even later - any news on this ?

[jmprieur]

you might want to try with the scope being "{client_id}/default"

[aloene]

@jmprieur Do you mean using "{client}/default" is working and supported on v2 endpoint ?

[ghost]

I need an example of this working with a Native Client. I have an Win8.1 application working with the Microsoft.Identity.Client 1.0.0. When I tried to upgrade to UWP and Microsoft.Identity.Client 1.1.2, the parameters changed. I tried modifying the ClientId to use the format here but it doesn't work. So the old API and old format works just fine, new API and new format give me a message: AADB2C90117: The scope 'api://2c2fb9e7-a056-4506-9638-ab5bf9e3ad2c' provided in the request is not supported.
My native client doesn't have a scope, so I'm not sure what, if anything, to use when formatting. Here's the latest try that's causing this error: api://2c2fb9e7-a056-4506-9638-ab5bf9e3ad2c . If I provide a dummy scope, it brings me to the log-in screen, but doesn't allow me to log in.

[rggammon]

@jmprieur - re: your "{client}/default" suggestion, I get -
AADSTS70011: The provided value for the input parameter 'scope' is not valid. The scope e3f68.../default is not valid.

[ghost]

If it's a native application, you might find some useful information in this thread: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/562

[rggammon]

thanks for the thread. In my case, I am trying to achieve what is alluded to in https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-limitations

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.

I can also switch to ADAL & the non-v2.0 endpoint as a work around.