Groups claims - Id token and access token

Questions
1

I’m working towards implementing authorization for my first party react web application that communicates with a .NET core web api.

For use in the client, I’ve created a ‘groups’ claim as part of the ID token to indicate what group (role) a given user is a part of. From the API’s perspective and for authorization purposes, I’ll need an additional claim added to the access token to authorize API requests, likely the same data contained in the ‘groups’ claim that was added to the ID token.

My question is what’s the preferred architecture or method for adding a claim to both the ID token for use within the client, as well as within the access token for API authorization.

Is it ok to create two ‘groups’ claims, one for the ID token and one for the access token? And if not, how should this handled?

2

Hi @Hassleboff

Usually the ID token represents the user’s details, while the access token represents the user’s permissions.

In this case, the best solution would be to have the group claim added inside the access token, which requires creating a custom claim inside the custom authorization server used (Admin >> Security >> API >> Authorization Servers >> your authorization server >> Claims or Admin >> API >> Authorization Servers >> your authorization server >> Claims if using the developer interface).

1 Like
3

@dragos

Thanks again! I’ve added the groups claim to the access token and that definitely covers the permissions aspect/authorization for the API.

I suppose my question is wouldn’t an additional claim be needed in the ID token as well to indicate a users role, group, etc.?

I would imagine the client needs some user detail to, for example, allow/deny access to certain routes, hide/show buttons that are dependent on the users role/group/permissions, etc. I would think that the authorization architected within Okta for securing the API would essentially be synonymous with client side ‘permissions’. (ex. If a user is only authorized to perform GETS on a given resource, then something client side should prevent the visibility of the UI control to perform the GET.)

Would this user attribute not come from some sort of claim within the ID token/user profile?

As a reminder, this is a first party app with no true access delegation. This app is the only client of the API.

  • Below post by Micah Silverman @afitnerd which outlines similar functionality with a Spring boot app.

https://developer.okta.com/blog/2017/10/13/okta-groups-spring-security

  • Below is a quick component I’ve created that displays what I’m shooting for/curious about.

<AuthorizedComponent

      allowedRoles={["app.userRole"]}

    >

      <Redirect to={"/some-route-based-upon-users-role"} />;

    </AuthorizedComponent>
4

Hi @Hassleboff

You can either set additional claims inside Okta in order to set granular permissions for CRUD operations or, based on existing values, you can set up a map in the application to provide specific values based on the claims received.

5

Thanks @dragos. I’ve used the application side map in the past and that works well. Regarding the additional claims within Okta, that’s what I’m curious about…how does that look within Okta. In a nutshell,

ID token - Added the groups claim to the ID token for client side use
Access token - ???

  • For the access token/use by the resource server, do I create a second groups claim and add it to the access token?

  • Do I create a custom app attribute (ex. appPermissions) that’s a string array, and during the group assignment, add an entry for each app permission (projects:read, etc.), and return those as a custom claim within the access token?

  • Do I authorize on the api side using scopes? The issue here again is that it’s a first party app and API, so there’s no true access delegation. I can treat it like it’s a 3rd party app, however I don’t believe Okta supports scope downscoping so I would need to find out how to handle an access policy failure if one of the scopes requested by the client isn’t approved

6

Hi @Hassleboff

The best solution would be to have the groups claim under the access token so that it can be leveraged by your application through the map and also by the resource server.

1 Like
7

@dragos

Thanks very much for your input. I suppose my only question/hesitation with this would be having the client inspecting the access token.

What are your thoughts on this?

8

Hi @Hassleboff

Indeed, the client can introspect the access token, however any modifications to it will automatically invalidate the signature.

9

Hi @dragos,

Thank you for this. I’m using the okta react sdk@1.3…do you know off hand if token introspection is available/baked into the sdk, or will this need to be achieved through additional calls?

10

@dragos

Is the introspect endpoint CORS enabled? I’m receiving a CORS error when calling it from the browser, calling from POSTMAN works without issue?

11

Hi @Hassleboff

I’ve checked now on my end an I can confirm that introspect endpoint is not CORS enabled.

12

Thank for good token

13

@dragos

With CORS not being enabled/unable to call the introspect endpoint from the browser, in order to examine the access token from the client, would this be considered legit?

image

By the way, I hope you all are able to stay safe and healthy!

14

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