I wrote about how we integrate Okta and Auth0

 using Auth0’s Social Connector (it runs OAuth2 behind the scenes). Today I will get into a bit more detail about how it’s done behind the scenes.

Our applications are registered directly with Auth0 as a “Regular Web Application”. This first layer of registration allows us to control 

. In other words, only applications authorized by our platform can communicate with our backend.

The second level authentication and authorization that we do is at the 

. This is where the Okta + Auth0 integration comes into play (there’s also 

 but we’ll get into that as a separate topic). The user is redirected to Okta to complete sign-in (enter your username, MFA, etc.) and then returned to Auth0 to continue with the login flow.

 script for that Social connector we configured to talk to Okta. In this script, the Auth0 runtime populates a number of parameters with useful return information from Okta. You get 3 things:

a ctx or context object which gives you access to the id token

and a callback, cb, for you to return a profile object to Auth0 that we use to construct the JWT

The access token is specific to the user who just completed the logon in Okta. We use this access token as part of the Authorization Bearer scheme to call the Okta OIDC UserInfo API (

https://developer.okta.com/docs/reference/api/oidc/#userinfo

). This allows us to fetch additional attributes about the user.

It is highly recommended to use an Okta custom authorization server for this purpose (

https://developer.okta.com/docs/guides/customize-authz-server/main/

). Why? Because the custom authorization server allows more control over the JWT that Okta mints (

). It’s also possible to move some of the custom claims being generated in Auth0’s 

 script to an Okta custom authorization server (it’s really up to you, but we prefer Auth0’s approach because Okta’s expression language pales in comparison to raw Javascript :) )

The return JSON from the Okta API call makes it very easy to parse properties and do additional processing. For example, here is part of our 

 object is what we return to Auth0 as part of our 

 script. This object is used by Auth0 to create the user profile and issue a JWT. This can be done like so at the end of the script:

To add a new claim to the JWT that Auth0 mints, all you have to do is to modify the 

 object to your heart’s content. For example:

 then? That is simply the user’s OIDC token and we can get that from one of the function parameter that Auth0 passes to us i.e. the 

Now that you have both the access token and id token, you can manipulate the final JWT that gets issued! Oh, one more thing — how do you remove a claim? Easy as pie:

When you view your the JIT created user in Auth0, you will see something similar to the image posted below where each field is generated from the 

 object that you manipulate. These fields can be used for 2 purposes — for auditing (you have a snapshot of the user the last time they logged on, so it’ really up to you what fields you want to populate for auditing purposes), and finally for JWT generation.

To get these fields added to the JWT token that Auth0 mints, you use another wonderful Auth0 feature called the login action flow (

https://auth0.com/docs/customize/actions/flows-and-triggers/login-flow

Here’s a sample of how you can do that:

If you need more information, feel free to reach out to us at 

Minting JSON Web Tokens (JWTs)