Okta SCIM App: Use OAuth Client Credentials Flow with AWS Lambda

This article is a follow up article to: How to Use AWS Lambda and CloudWatch as the ultimate SaaS integration testing tool.

In the previous article, we used a real life example, integrating Okta SCIM App with Salesforce, to demonstrate how AWS Lambda and CloudWatch can be used to test and troubleshoot SaaS integrations. With the shared tool, which consists of a small piece of nodejs code and a layer for axios, it is possible to watch each Request and Response between 2 SaaS instances. As a specialist for SaaS integrations, this tool has been a lifesaver for me in many circumstances.

Now let's take this tool one step further.

Because the Okta SCIM App only provides SCIM 2.0 Base Url and OAuth Bearer Token input fields, that means we need to generate the OAuth Bearer Token out-of-band (we used Postman in the previous article). This is not ideal for transitioning an integration to Production...

Wouldn't it be nice to be able to use OAuth Client Credentials Flow with the Okta SCIM App? Well, this is what Okta has to say about the possibility:

"Okta doesn't support the Client Credentials or Resource Owner Password Credentials Authorization grant flows for SCIM. The Authorization Code grant flow is more common in SaaS and cloud integrations and is also more secure."

Hum...The Authorization Code grant flow is more secure? I am not sold yet on this statement. And anyway, this is just not a possibility with most real life SCIM API implementations... So we are left with 2 options: Either we rewrite the Authentication Stack for a SCIM API, or we find a way to enable Okta SCIM App for Client Credentials flow. Let's pick the second option.

One thing to know about OAuth and Access Tokens is that it is possible to create our own, and inject metadata into it. Then, leveraging an AWS Lambda function, it is possible to extract the Authentication Url, Client ID and Client Secret, to obtain the Access Token.

The only downside to our strategy is that Authentication happens with every Okta SCIM API call, but that is something that adds less than 1 second to each API Call, which is not really a bottleneck. The good thing about this strategy is that we do not need to store credentials within our AWS Lambda function, or in a temporary location like an S3 bucket, which allows us to do without all kinds of security concerns around protecting those credentials.

Let's start by creating a JSON string for our custom Okta Access Token:

Then the next step is to use a Base64 Encoding tool to turn this JSON string into a Token:

We also need to build a Url which is a combination of the AWS Lambda function Url and the Salesforce SCIM API Url, just like we did in the previous article:

{Lambda function Url}/{Salesforce instance}.develop.my.salesforce.com/services/scim/v2/Users

Now let's use our special Url together with our Base64 token to configure our Okta SCIM App:

We can use AWS CloudWatch to see what is happening behind the scene, as always:

The complete configuration of the Okta SCIM App for Salesforce is beyond the scope of this article. We are using Salesforce as an example only. It is possible to configure the attributes and mapping between Okta and Salesforce, just as if the connection was happening directly between Okta and Salesforce. However, we are now able to use the OAuth Client Credentials flow.

Below I will share the modified code I used for the Lambda function in nodejs. I hope you have enjoyed reading this article. Leveraging AWS Lambda and CloudWatch has been a great way for me to learn and design new integrations, and I hope you can benefit too!