Does Okta support Client-Level Claims when used for OpenID Connect


#1

I have been looking over different out-of-the-box OpenID Connect Providers, and a concern that has come up is how to assign a claim, such as role, on a per-application, per-environment basis. I understand that role claims are themselves a bit out of scope of the official OpenID Connect spec, but it seems that various providers have their own implementations of how to support such a feature.

I was looking at Auth0, and it seems like they have a feature for managing per-user per-application claims via something they call a User Metadata feature.
Auth0 Claims Documentation

I was curious if Okta had something similar.


#2

Okta supports client level claims. We have multiple approaches depending on how you want to accomplish your goal and what product you are using from Okta (SSO vs API Access Management).

  • SSO product is intended for more standard enterprise scenarios where you want to pass user identity claims in ID tokens from the directory (traditional federation use case)
  • API Access Management product provides a custom OAuth Authorization Server + OpenID Provider for your application where you can fully customize the ID Token and Access Token.

Each OAuth client is modeled as an Application in Okta. Each application can define its own schema for users assigned to the application called App User schema in Okta terminology. This is managed by visiting Directory->Profile Editor in the Admin UI,

These attributes can be referenced when issuing claims. Our SSO product doesn’t provide granular control of claim mappings and just passes the entire profile with the profile scope. The API Access Management product lets you define custom claim mappings using expressions. This approach is useful if you want to persist data specific to a user + app.

We also have support for custom properties as part of the application. This is useful if you want to persist data that is specific to the client and not client + user. These properties need to specified via the API but can be referenced in claim mapping using Okta EL.

The free developer product includes support for both products. I recommend using a custom Authorization Server as it provides the most amount of flexibility.


#3

Hi @mcguinness,

I might be hitting all the wrong options on screen, but how can I add a field that is specific solely to a single application?

As a simple example, I would like to have two applications, each having their own “system_home” field and going through the same Authorization server. I tried adding the field in the Profile Editor on both applications (App1 having a value of “HDQ”, and App2 having “FDS”).

However, I am unable to:

  1. Obtain those values from the Profile Editor Preview pane without specifying a user. These apps will be using the client_credentials OAuth dance, so I do not think that providing a user for the preview action makes much sense.
  2. Reference the hardcoded values in the Okta Claims panel (using an Okta Expression app.system_home) and issuing a sample JWT using client_credentials. The JWT token is shown on the “Token Preview” screen but the custom claim is not included.

Do you know what I may be doing wrong?

Thanks,
Justin