A Solution Overview and Architecture for an Okta Based Customer Identity and Access Management
In today’s information-packed, multi-channel yet more and more regulated digital world, whether you just started a new business and are building your product, or you are a large business that has many applications, customer identity is always the fundamental and shared service in the application architecture. This is especially true in a cloud based architecture where you have multiple tenants in a distributed system. You need a unified customer identity solution to gain insights of your customers and provide them the best digital experience.
Okta as a SaaS Based Identity Platform
Among many workforce and customer identity solutions, platform services and integrations Okta offered as a SaaS, or Identity as a Service (IDaaS), solution, I will mainly focus on Authentication, Self Service Registration (SSR) and Authorization in the Customer Identity and Access Management (CIAM).
Okta not only offers a cloud based application for customer organizations to launch SSO applications and administrate the instance, it also provides multiple integration options (you will need to enable SSR if you use #1 and #2 below).
- Okta Hosted Sign In Page
This means you will use the OOTB sign in page Okta provides for your application. Okta will host and manage the sign in and sign up experience. You can customize the experience by customizing the URL domain, sign in page HTML, labels and links. You can simply create your application in Okta and put it behind Okta’s authentication page. This is the least flexible options of the three but is also a completely managed cloud based option, which means fastest time to market and least codes to manage.
2. Sign In Widget
The second option is to embed the Okta Sign-In Widget into your application. The Okta sign-in widget is a Javascript code that is available either through Okta CDN or NPM. You can customize the widget or develop custom event handlers based on your needs. With this option, you still follow the same Okta default flows and procedures underneath, but you have more flexibility on where and how the sign in widget display in your application and you don’t need to develop all the codes that connect to Okta.
3. Custom UI with Okta SDK and API
That last option is to develop your custom sign in and sign up UI for your applications with Okta SDK and/or API. This is the most flexible option, you have the max control over the use case (i.e. passwordless sign up and authentication), user experience (i.e. progressive profiling, fields, messages, internationalization), business logic (i.e. send custom email from your email server when user is locked out) and tech stack of your choice, but of course you will need to develop those.
Solution Architecture
The solution architecture I build here is a sample reference for you to consider with your own circumstances.
The use case here is that I am building a new web application for my B2B business and it needs a user sign up and sign in experience. There’s also an admin section in my app that only customer admins can have access.
There are three main components in this architecture: AEM (Adobe Experience Manager), AWS (Amazon Web Services) and Okta.
Web/ UI
I choose to develop the web application as a SPA (that includes the custom sign up, sign in and admin experience) because I want to have full control over the look and feel/branding, flow and business logic of the experience. Leveraged AEM as a headless Content Management System for the SPA, I can let the same content management team to manage all the content authoring, publish workflows and translations in one place.
AWS
The SPA will be cached and served over the edge by Amazon CloudFront and deployed in Amazon S3.
The REST APIs for the SPA will be developed and deployed in different serverless Lambda functions, like this example. They are fronted by a Amazon API Gateway to manage all API accesses, rate limits, authentication and authorization etc.
For a more frictionless and fast sign up experience, I want to provide the least minimum attributes for user to sign up at first. But since I am a B2B business, there may be many regulations, business processes and workflows that need to happen after a user account has been created (in Okta in this case).
So after the registration is complete and user account is created in Okta, I will send a message/signal (I am doing it in registration API, but I can also do it via Okta event hook and have Okta called a Lambda service) to a AWS SNS (Simple Notification Service), it will then fan out to all the business services subscribed to the account registration topic, like an email service to send out a welcome message to the user, an account validation service to ensure the registered account is compliant with business policy, a marketing systems integration service to push a new lead to the marketing automation system like Marketo, and then sync to Salesforce for my sales team to follow up. To enable fault tolerance and performance, I will front each of those services with a AWS SQS (Simple Queue Service) so that these message payloads can be cached and queued before they are delivered and consumed by the downstream services.
Moreover, for the account validation service, I will have a AWS Step Functions to handle all the steps and workflow required to validate the user account. For example, first of all I will call a third party identity compliance check service API. If it comes back as pass, I will update the user record in Okta and also Marketo lead to indicate the same; if it comes back as fail, I will have a manual step to review the account internally and confirm compliance. Below is a workflow diagram for the same.
Okta
Okta will be the source of truth for user identity (Universal Directory), IDP (identity provider) and engine for user lifecycle management, policies (sign on, password, MFA and IdP discovery) and API Access Management.
The authorization of the application will follow OIDC standard and it will allow/deny access. Since SPA is a browser based application, the OAuth group recommends to use Authorization Code flow with the PKCE as the code flow to exchange ID and access tokens.
I will create a custom authorization server for my application in Okta. The customer admins will be put into a admin group for the customer, so that the access policy can be associated with a group instead of a specific person and align with best practice. Then in the authorization server, I will create a new admin scope. After that, I will also set up an access policy and rule that only the customer admin groups can have access to the admin scope. Furthermore, I can create custom attributes in the Okta user profile schema to identify what kind of admin role the user is, i.e. org admin role can manage everything for the organization, group admin role that can only manage specific groups within the organization etc. Then I can set up a claim for the admin scope and output this user attribute into the access token jwt using Okta expression language. Now my admin screen and customer administrative REST APIs can have a role based access control (RBAC) to the person that is logged in.
Architecture Diagram
What is New?
There are some upcoming new Okta features to look out for and will make a difference for CIAM.
Workflows
Okta Workflows provides workflow engine for identity centric processes automation. It’s currently GA for workforce identity. When it’s rolled out to customer identity, it should accelerate some of the common CIAM lifecycle management use cases.
Identity Engine
Okta Identity Engine separates the core identity lifecycle (from registration to authentication to authorization) into four steps: Identity, Authorize, Enroll and Issue, so that you can customize and extend each individual component to achieve tailored experience like passwordless authentication and progressive profiling.
Ready to Build Your Own?
CIAM is never an easy task, especially for large enterprises, it needs to be built with performance, scalability, resiliency, security and user experience in mind. I hope this blog sheds some lights on your design and architecture. You can sign up for a free Okta developer instance and AWS account and start to play with different components mentioned in this blog. There are also tons helpful blogs, tutorials, videos and webinars online.
