Question in regards to JWT structure and server authorization

[Oxyrus]

Good day everyone.

Today I decided to setup Auth0 to be able to generate JWT used to authorize access to an API written in ASP.NET Core 2.2, I did so following this wonderful tutorial.

However, when the time came to Authorize access to my API in each endpoint based off the permissions I encountered something interesting, the class HasScopeHandler was using scope instead of permissions.

For context, this is the original class:

public class HasScopeHandler : AuthorizationHandler<HasScopeRequirement>
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, HasScopeRequirement requirement)
    {
        // If user does not have the scope claim, get out of here
        if (!context.User.HasClaim(c => c.Type == "scope" && c.Issuer == requirement.Issuer))
            return Task.CompletedTask;

        // Split the scopes string into an array
        var scopes = context.User.FindFirst(c => c.Type == "scope" && c.Issuer == requirement.Issuer).Value.Split(' ');

        // Succeed if the scope array contains the required scope
        if (scopes.Any(s => s == requirement.Scope))
            context.Succeed(requirement);

        return Task.CompletedTask;
    }
}

However, when I downloaded one of the SPA examples provided to be able to get a JWT token for a given user (if it’s possible to generate one from the dashboard please let me know), I realized the JWT structure was a little different, its scope property doesn’t contain the permissions, these are listed in their own property permissions.

{
  "iss": "https://my-application.auth0.com/",
  "sub": "auth0|5d2921e518fa750db74f7559",
  "aud": [
    "https://someendpoint.azurewebsites.net",
    "https://my-application.auth0.com/userinfo"
  ],
  "iat": 1562986382,
  "exp": 1563072782,
  "azp": "WXnuME1d5o84FNqTuUKc5Ms16tjm1MTs",
  "scope": "openid profile email",
  "permissions": [
    "view:itemcategories"
  ]
}

So of course no request will ever work because it will look for the permission inside of the scope property. Changing the class mentioned previously to look inside the permissions property works just fine.

public class HasScopeHandler : AuthorizationHandler<HasScopeRequirement>
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, HasScopeRequirement requirement)
    {
        // If user does not have the scope claim, get out of here
        if (!context.User.HasClaim(c => c.Type == "permissions" && c.Issuer == requirement.Issuer))
            return Task.CompletedTask;

        // Split the scopes string into an array
        var scopes = context.User.FindFirst(c => c.Type == "permissions" && c.Issuer == requirement.Issuer).Value.Split(' ');

        // Succeed if the scope array contains the required scope
        if (scopes.Any(s => s == requirement.Scope))
            context.Succeed(requirement);

        return Task.CompletedTask;
    }
}

So I guess at this point my question is, was there a change in how the permissions are set in the JWT since the tutorial was published? And, is it fine to just leave my class as it is so it looks inside the permissions property?

Thanks a lot for your time!

[mathiasconradt]

Was there a change in how the permissions are set in the JWT since the tutorial was published?

The tutorial was created before RBAC Core features, including the ability to add the permission claim to the access token, were added to Auth0. So the tutorial entirely refers to the scope claim instead of the permissions claim.
It’s not a change but rather an addition to cover a different scenario.

The permission claim was added for the scenario where you are building a first party client and API. In this case you are not working on delegated authorization (trying to collect consent from the user), you are trusting the authorization server to tell you what permissions the user has. Your client won’t be requesting any scope and your API will be validating what permissions the user has by checking the permissions claim.

And, is it fine to just leave my class as it is so it looks inside the permissions property?

Yes, if above described scenario applies to yours, it’s perfectly fine.