Attribute-based Access Control via claims

Hi,

I am exploring the option of using scopes & claims to setup Attribute-based authorization for our application. If we use many claims is there a chance that the access token will become too big?

Also, are there any examples of how you do Role-based authorization?

Thanks

I think, it really depends on what you call “many”. JWT itself per-se doesn’t have a limitation, but the fact that it can be send as a part of URL, makes it theoretically possible to hit some limits. I’ve seen cases where URL became too long for some proxies/frameworks to be upset.

If you are going to use scopes, it might be a substitution for sending a lot of claims back to your application, for it to make an authz decision. Your authz server in Okta can make the authz decision instead, based on user groups/attributes and scopes requested, for example. If it’s something achievable in your case, I’d say go this route

Phi1ipp,

Thank you for the response.

Using Okta authz server to make the authz decision based on groups/attributes and scopes sounds like a very good approach.
Would you be able to post a link to an example doing that or some documentation? I haven’t been able to find anything on your docs site.

Thanks

Lol, it’s not mine :slight_smile: I’m just a developer like you, but you could’ve google the link to the documentation - https://help.okta.com/en/prod/Content/Topics/Security/API_Access.htm

Phi1ipp,

Thanks. I saw this website yesterday. It didn’t really address what I was looking for which was how are Roles setup in Okta. I found a Java example and it seems it was a terminology issues - I think Okta uses groups as roles at the user level. Meanwhile they have some predefined ROLES for a few ADMIN Okta groups to which I personally have no access to but the docs mention them.

I’m sorry, I’m not quite following you. Admin groups/roles (call them as you like, I guess we both understand what is meant) are only useful from administration perspective, not sure why you are focused on them.

If you want to practice creating groups as admin, go and create yourself a developer account, where you can be super admin, so you will be able to do whatever you want.

The groups/roles I was referring in my previous post are regular user groups, which can be used as a basis for authz decisions made by Okta authorization server.

I come from the SpringSecurity world where they use Roles (which was a set of actions in the implementations of my project). I think I was looking for something similar with Okta. In my understanding for Okta groups are used as roles where apps or users can be assigned to the groups but if one wants to get more granular one can use scopes&claims. In any case thanks for your help.

It is possible to enrich the ID/Access Token using Hooks, and provide additional Claims which includes Fine Grained / Corse Grained authz like a list of Entitlements or/and a list of resources you are allowed to. SpringSecurity will be used to enforce the access.
Take a look on this article: