Okta ABAC implementation using OAuth 2.0

I am new to Okta. And we are planning to purchase okta OneApp package. Our need is to provide them attribute based access control to forms fields of different entities including user as well.
I have gone through the okta documentation and only find one page(https://developer.okta.com/books/api-security/authz/attribute-based) about ABAC and finding it difficult to get any further support or detailed helping material , how actually okta helps to implement ABAC , any java example or further details will be highly appreciated and motivate us.

It will be great if anyone can guide me in the right direction and how ABAC will be implemented and achieved using Okta.


First off, I’m going to assume that the OAuth access token is the source of the attributes used to determine access control. An ABAC solution may use the OAuth token only for the authenticated user ID or for additional attributes. A lot of the specifics for this is dependent on the application frameworks for both the UI and the back-end server, so all I can give you are generalities
In Okta:

  1. Determine the attributes you will use for your access control.
  2. Create one or more claims that will put these attributes into an access token.
  3. Assign the claims to every scope or create specific scope(s) associated with these claims.
    Note: You may also want to define a policy that grants these scopes based on specific group membership. This does complicate the Okta configuration and the operational implications may outweigh the added security.

In your application,
a) ensure the ‘user’ or ‘client’ requests an access token from Okta using either the openid scope or the scope created in step 3).
b) supply the access token in all requests to your application server for any endpoint requiring authorization. Typically, this is a REST web service and the token is supplied in the HTTP authorization header as a Bearer token.
c) In the back-end server at the point where an access control decision is made, determine access based on the value of the appropriate claim in the token. I strongly suggest you use some application security framework, such as Spring Security (bundled with Spring Boot), Oracle Platform Security Services, Apache Shiro, or whatever to validate the access token and create a security context based on the token. Do not roll your own!

1 Like

I’m having the same problem. If we take the example provided on the OKTA site (linked above) how specifically does the application grant a specific user access to a specific playlist. Given a specific user and a specific playlist how does the application know if that user has “edit:playlist” permission? The example goes about 50% into explaining it and then stops.

Here’s what the example says:

Leia presses the “Edit Playlist” Button → Request is routed to PEP → PEP constructs an authorization request → PEP requests edit:playlist, edit:description scopes along with some identifying information like user id → PDP uses this information to lookup policy, user info, and returns allow or deny.

Is the application supposed to create a new scope in Okta every time a new playlist is created? This example does not include a playlist ID in the hypothetical authorization request. I would have expected it to request the “edit:playlist:1737428373” scope. Are they omitting this detail for brevity? If not, is the application supposed to somehow merge its knowledge about ownership with Okta’s incomplete picture of ownership - how would that work?

Edit: It would be much more useful for Okta to implement a sample application that actually does something interesting - like this playlist example in the docs. Instead they are all oversimplified and just read the email claim from the auth token. Not useful.

1 Like

Yes, it would be nice for Okta to supply a working fine-grained access control implementation. However, I wouldn’t hold my breath for it. The basic issue here is that there are two general purpose access control frameworks in place.

In the ABAC architecture, the PDP uses the security context to determine if the operation on the specific resource. In some implementations, this is performed by returning a ‘promise’: essentially an additional ‘where’ criteria to append to the SQL statement the application is about to execute. In your example, if the user has the ability to edit ANY playlist, the PDP would allow access with a ‘promise’ of something like, “playlist_owner = current-user-id”. In other impls, the PDP would query PLAYLIST_OWNER table directly. In either case, a ‘general’ OAuth scope of edit:playlist would suffice.

As a framework, OAuth does allow for fine-grained access control as long as the authorization server supports it. Okta’s supplied authorization server implementation will never natively implement this, as it would require a query into the application’s database as well as application specific logic. Thus, you would need to write your own auth server that understands resource instance specific scopes (edit:playlist:1737428373) and use that. This would allow the PDP to only need to see if the appropriate scope was present in the access token to grant/deny the operation.

While you could create a set of scopes for each resource instance (playlist) within an Okta auth server, I would hesitate to do so, as you also need to have an appropriate access control policy defined. To me, keeping this all in sync between an application an Okta would be a challenge operationally.