WebAPI Can't read user scope claims

[npnelson]

I got this sample to work, but I'm trying to take it a step further by reading the daemon's permissions so I can decide if it has access to a particular WebAPI call. For instance, some Daemons might have access to the entire WebAPI- I would give those one Client ID and other Daemon clients might have access to just one or two of the WebAPI methods. Those would get a separate Client ID which would have a different permission assigned.

In this case, I simply delegated the "Have full access to the To Do List service" to the TodoListDaemon just like this "In the Permissions to Other Applications configuration section, select the TodoListService application, and add the full access delegated permission. Save the configuration."

I set a breakpoint in the TodoListController.Get method to examine the scope claims and they come back null.

  public IEnumerable<TodoItem> Get()
        {
            //
            // The Scope claim tells you what permissions the client application has in the service.
            // In this case we look for a scope value of user_impersonation, or full access to the service as the user.
            //
            Claim scopeClaim = ClaimsPrincipal.Current.FindFirst("http://schemas.microsoft.com/identity/claims/scope");

//THIS COMES BACK NULL EVEN THOUGH I ASSIGNED THE Daemon the user_impersonation in Azure portal

            if (scopeClaim != null)
            {
                if (scopeClaim.Value != "user_impersonation")
                {
                    throw new HttpResponseException(new HttpResponseMessage { StatusCode = HttpStatusCode.Unauthorized, ReasonPhrase = "The Scope claim does not contain 'user_impersonation' or scope claim not found" });
                }
            }

I would expect to see the user_impersonation claim here, not null. I've tried different variants, none of which I had any luck with.

What could I be missing?

[skwan]

Today Azure AD does not send scope claims when using the client credentials OAuth flow. The daemon samples use client credentials (as opposed to a delegated OAuth flow, like the authorization code flow or the on behalf of flow). The configuration UX is unfortunately misleading because you can set what looks like a scope to be sent, but nothing get sent. We are working on adding support for this scenario. Net, for now you will need to make authorization decisions based on just the claims you receive in the access token.

[npnelson]

I usually don't leave a simple "thank you" comment because it adds noise, but I just wanted to say I am very thankful for your quick and thorough response (and especially for saying you are working on adding support for this scenario). We just started using Azure and so far, I am pretty impressed (except for the Portal UIs).

Thanks again, keep up the good work!

[cwe1ss]

@skwan Has there been any progress on this? Can I get the scope/permissions somehow in a client_credentials call?

[jmprieur]

Scopes are about the AAD V2 endpoint (which you get access to using MSAL.Net). this sample is about the AAD V1 endpoint (which you get access token to using ADAL.NET).