API Permissions not in User.Claims

Help
,
1

I’m using Blazor Server.

I’m using Auth0 for application authentication and I’m using API Permissions for more fine-grained authz. Most of it is working, but I’m at a loss on how to get the API Permissions into the User.Claims.

  1. I’m able to get the right permissions from the access token using HttpContext.GetTokenAsync(“access_token”)

But, I was expecting the API permissions to be included in User.Claims

Should the API permissions be there by default or do I have to do something special?

I have flipped the bit in settings for RBAC and include in Access Token, and they are there.

But they just don’t show up in User.Claims. I could look at creating a customerAuthenticationStateProvider, but I think I’m missing something simple.

Thanks!

1 Like
2

Hi @jonnyb , welcome to Auth0!

The permissions should be there. If the API is configured:

  • with RBAC and
  • enabled the Add Permissions in the Access Token toggle and
  • your test user is correctly assigned to permissions,

then the “permissions” claim should be available in the access token.
Do you see the “permissions” claim there?

3

Here’s my full setup:

  1. Default app

  2. API app with one permission “download:files”

  3. User is assigned to both the Admin role which has the download:files permission as well as the direct assignment to the permission.
    image

  4. RBAC toggled

    image
    image805×352 20.7 KB

  5. Login flow:

image

exports.onExecutePostLogin = async (event, api) => {
  const roleClaim = 'http://schemas.microsoft.com/ws/2008/06/identity/claims/role';
  
  if (event.authorization) {
    api.idToken.setCustomClaim(roleClaim, event.authorization.roles);
  }
};
  1. Program.cs
builder.Services.AddAuth0WebAppAuthentication(options =>
{
    options.Domain = builder.Configuration["Auth0:Domain"]!;
    options.ClientId = builder.Configuration["Auth0:ClientId"]!;
    options.ClientSecret = builder.Configuration["Auth0:ClientSecret"]!;
    options.ResponseType = "code";
})
.WithAccessToken(options =>
{
    options.Audience = builder.Configuration["Auth0:Audience"];
    options.UseRefreshTokens = true;
});

To re-iterate, everything is working EXCEPT my User.Claims doesn’t have permissions.

Thoughts?

4

Hi @jonnyb ,

Thanks for this summary!

Alright, you mean ID token.

Could you try updating a bit your Actions script:

exports.onExecutePostLogin = async (event, api) => {
  const roleClaim = 'http://schemas.microsoft.com/ws/2008/06/identity/claims/role';
  
  if (event.authorization) {
    api.idToken.setCustomClaim(`${roleClaim}/roles`, event.authorization.roles);
  }
};

And see if the ID token after decoding with jwt.io contains the claim added via Actions?

5

Thanks for having a look! I updated the Actions script. The Roles are there, but the API Permissions are not.

Any other ideas?

6

Hi @jonnyb , welcome in 2024!

After additional investigation I can tell that the role-based API permissions are intended to be present in the Access Token and with the Actions Script it’s possible to only enrich the ID token with Roles cliam.

One way that comes to my mind, if you need this data within the ID token, is to update the user’s app_metadata or user_metadata object with the API permissions and add a custom claim to the ID token containing this metadata (in a similar way you added the Roles claim).

This Management API endpoint lists user’s permissions (both assigned directly and ones that come from Role assignment) - Auth0 Management API v2
They are listed per the resource_server_identifier (your API identifier).

In the Actions script you can also refer to the event.resource_server object and try to use this identifier to extract only the relevant for the login context API permissions.

One of our community folks has tried to implement it using rules (soon deprecated) so maybe you can use it as a reference when building Actions script- Accessing the permissions array in the access token - #10 by ryantomaselli

7

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.