# Groups claims - Id token and access token

**URL:** <https://devforum.okta.com/t/groups-claims-id-token-and-access-token/8521>\
**Category:** Questions\
**Created:** [March 18, 2020, 6:18pm UTC](https://devforum.okta.com/t/groups-claims-id-token-and-access-token/8521 "2020-03-18T18:18:02Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![Hassleboff](https://avatars.discourse-cdn.com/v4/letter/h/e36b37/32.png) [@Hassleboff](https://devforum.okta.com/u/Hassleboff)\
**Post date:** [March 18, 2020, 6:18pm UTC](https://devforum.okta.com/t/groups-claims-id-token-and-access-token/8521/1 "2020-03-18T18:18:03Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![dragos](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/dragos/32/1313_2.png) [@dragos](https://devforum.okta.com/u/dragos)\
**Post date:** [March 19, 2020, 12:47am UTC](https://devforum.okta.com/t/groups-claims-id-token-and-access-token/8521/2 "2020-03-19T00:47:31Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![Hassleboff](https://avatars.discourse-cdn.com/v4/letter/h/e36b37/32.png) [@Hassleboff](https://devforum.okta.com/u/Hassleboff)\
**Post date:** [March 19, 2020, 12:53pm UTC](https://devforum.okta.com/t/groups-claims-id-token-and-access-token/8521/3 "2020-03-19T12:53:13Z")

</div>

@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](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>
```

---

<div class="post-metadata">

**Author:** ![dragos](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/dragos/32/1313_2.png) [@dragos](https://devforum.okta.com/u/dragos)\
**Post date:** [March 20, 2020, 12:28am UTC](https://devforum.okta.com/t/groups-claims-id-token-and-access-token/8521/4 "2020-03-20T00:28:38Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Hassleboff](https://avatars.discourse-cdn.com/v4/letter/h/e36b37/32.png) [@Hassleboff](https://devforum.okta.com/u/Hassleboff)\
**Post date:** [March 20, 2020, 2:37pm UTC](https://devforum.okta.com/t/groups-claims-id-token-and-access-token/8521/5 "2020-03-20T14:37:56Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![dragos](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/dragos/32/1313_2.png) [@dragos](https://devforum.okta.com/u/dragos)\
**Post date:** [March 23, 2020, 6:09am UTC](https://devforum.okta.com/t/groups-claims-id-token-and-access-token/8521/6 "2020-03-23T06:09:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Hassleboff](https://avatars.discourse-cdn.com/v4/letter/h/e36b37/32.png) [@Hassleboff](https://devforum.okta.com/u/Hassleboff)\
**Post date:** [March 26, 2020, 7:10pm UTC](https://devforum.okta.com/t/groups-claims-id-token-and-access-token/8521/7 "2020-03-26T19:10:51Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![dragos](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/dragos/32/1313_2.png) [@dragos](https://devforum.okta.com/u/dragos)\
**Post date:** [March 27, 2020, 12:34am UTC](https://devforum.okta.com/t/groups-claims-id-token-and-access-token/8521/8 "2020-03-27T00:34:27Z")

</div>

Hi @Hassleboff

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

---

<div class="post-metadata">

**Author:** ![Hassleboff](https://avatars.discourse-cdn.com/v4/letter/h/e36b37/32.png) [@Hassleboff](https://devforum.okta.com/u/Hassleboff)\
**Post date:** [March 30, 2020, 12:37pm UTC](https://devforum.okta.com/t/groups-claims-id-token-and-access-token/8521/9 "2020-03-30T12:37:50Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Hassleboff](https://avatars.discourse-cdn.com/v4/letter/h/e36b37/32.png) [@Hassleboff](https://devforum.okta.com/u/Hassleboff)\
**Post date:** [March 31, 2020, 3:06pm UTC](https://devforum.okta.com/t/groups-claims-id-token-and-access-token/8521/10 "2020-03-31T15:06:52Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![dragos](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/dragos/32/1313_2.png) [@dragos](https://devforum.okta.com/u/dragos)\
**Post date:** [April 1, 2020, 5:35am UTC](https://devforum.okta.com/t/groups-claims-id-token-and-access-token/8521/11 "2020-04-01T05:35:34Z")

</div>

Hi @Hassleboff

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

---

<div class="post-metadata">

**Author:** ![DaveBass](https://avatars.discourse-cdn.com/v4/letter/d/dbc845/32.png) [@DaveBass](https://devforum.okta.com/u/DaveBass)\
**Post date:** [April 1, 2020, 8:56am UTC](https://devforum.okta.com/t/groups-claims-id-token-and-access-token/8521/12 "2020-04-01T08:56:18Z")

</div>

Thank for good token

---

<div class="post-metadata">

**Author:** ![Hassleboff](https://avatars.discourse-cdn.com/v4/letter/h/e36b37/32.png) [@Hassleboff](https://devforum.okta.com/u/Hassleboff)\
**Post date:** [April 6, 2020, 6:21pm UTC](https://devforum.okta.com/t/groups-claims-id-token-and-access-token/8521/13 "2020-04-06T18:21:37Z")

</div>

@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](https://global.discourse-cdn.com/oktadev/original/2X/5/532494f49e5d1624da39bfafff44e38e18188481.png)

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

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/oktadev/original/1X/589c4c5f80de422d01f47cee7185a7fb8227835c.png) [@system](https://devforum.okta.com/u/system)\
**Post date:** [January 23, 2024, 11:05pm UTC](https://devforum.okta.com/t/groups-claims-id-token-and-access-token/8521/14 "2024-01-23T23:05:21Z")

</div>

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