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) for user level authentication and authorization 

Minting JSON Web Tokens (JWTs)

I’ve joined Human Managed — a data company that empowers decision — in late December 2021 as a front end developer. In a short amount of time, I went through a steep learning curve, working with technologies and processes that I have never worked with before.

One of those is Git, a distributed, open-source version control (VCS) that enables you to:

revert to earlier code version when needed

Back in my college days, I used to code without any version control tool like Git. What I did was copy and paste source code folders and rename it with a version number. My reasoning back then is, since I do code alone, then there’s no point in using a version control system. Lo and behold, this idea backfired to me in my thesis project. There was a time when I needed to update a block of code for a fix, and it took me hours to do so.

I used to agree with the guy at the bottom😂

I knew that I needed to learn git when I joined HM. I won’t be coding alone anymore since I’ll be collaborating with my colleagues. When I was trying to learn it during my first few weeks, I initially thought it was really complicated since there are a lot of commands that you need to understand. But when I started to contribute in our internal codebase, I (also with the help of my colleagues) managed to learn it along the way. I have lots of realizations on how this tool can benefit myself before and could’ve made me more productive back then, how I wish I learned about it sooner!

 to store our source code, keep track of our changes for every apps per microservices and run a CI/CD pipeline to ensure that stages are automated and done correctly.

Through git, we have a commit ID which keeps track of our changes. We can always go back to whichever version we have, in any cases that we wish to.

For example, imagine you are working on a feature within a webapp and made around six commits already. You tested the application, then found that there is a bug in your app. Upon checking, you realized that the bug was caused by the initial commit you had in the source code. With git, you can revert a change and undo it, so you can go back to the original state of the source code.

In our applications, we use GitLab as our git-based web platform environment for version control and source code management. Every day, there are changes to be made in the codebase. A developer can work concurrently with the other one through git since we utilize its branching functionality and it being a decentralized version control system. We create a branch for a specific update in our webapp, and merge it to the main ‘production’ source code once it’s finished. This way, we are not dependent on each other if we want to make changes to our applications. We can do things seamlessly without the worry of having any conflicts with what we are doing.

 is used as our DevOps platform. Since it is git-based, we use GitLab as our remote repository to store our source code. An event is triggered via git push/commit to the remote which will execute a CI/CD pipeline through GitLab. We use it to run automated build, test, and deployment. Through gitlab, we can deploy apps immediately without the need to wait for someone to finish something, since steps are already automated.

Every action we do within our internal repositories are tracked via webhook which is configured in a CI channel wherein relevant individuals are added. We use this as our collaboration method to notify and make everyone aware on what’s happening to our apps in microservices.

Using GitLab enables us to automate majority of version control and source code management. It’s beneficial for software engineering since manual steps are already taken out of the picture through its automated devops functionalities.

Imagine doing manual build, test, and deployment for your applications. You’ll go back to the days where it’s not as efficient as compared to the automated stages that a devops tool like GitLab can offer. For sure it must have brought a lot of headaches to every developer before! Lucky enough, we live in an advanced tech-era now where everything can be automated already.

. In layman’s term, this is the set of instructions that you need to configure to automate all the actions/stages that you’ll be automating in your application.

Someone just needs to understand how to write this CI file, and all the end-to-end stages for CI/CD will be automated already. That’s how handy and powerful this file is!

This is just the beginning of our code automation story. Just like git, this narrative can be further 

 to areas like application security, automated deployments, and gitops. But that would be for another blog! 😊

Note: This blog was originally published in August 2022 and has been updated for accuracy. 

Categories

DevSecOps

Minting JSON Web Tokens (JWTs)

Automating and securing code management with Git