OKTA Architecture & Data Flows (External and Internal)

OKTA has evolved as a matured IDAM platform in the industry in the recent few years where it has outshined Microsoft AD and ADS solution and helped organization in integrating the SSO/MFA features enterprise wide.

In this article I am trying to show how easily OKTA SSO can be integrated with multiple applications for internal and external users.

The below section has been divided into two different parts:

a) OKTA Identity and Access Management Architecture.

B) OKTA User data flow.

Below section is for OKTA Architecture which explains how to create an app in OKTA so that external users can sign in:

Let’s talk about OKTA Identity and Access Management Architecture. In this architecture, I am trying to explain how organizations’ external and internal users will interact with multiple application over the OKTA SSO which included multiple OKTA tenant (Internal OKTA and External OKTA systems).

For External Users: For any organization to manage external users identity, the best way to approach is to have an external OKTA tenant. The external OKTA tenant can be easily integrated with any external APP/public application using OKTA’ widget which provides the OIDC (OIDC stands for “OpenID Connect”. It is an authentication protocol which allows to verify user identity when a user is trying to access a protected HTTPs end point) supported widget to authenticate.

In the OKTA external tenant, the app owner can create an application, user group, user profile template and sign on methods.

Below is the screen shot of how you can create an app in OKTA external Tenant:

Step 1: You can click on OKTA App and Create button:

Step 2: You can put the app name, sign in redirect where you want the sign-in screen and where you want to redirect in case of sign out. Once the OKTA app is created, you can configure the OKTA sign-in widget into your application and from there the users can start the sign-in process which takes into the flow of getting authenticated and having token in the case of SSO.

External user registrations steps:

Step 1: The external users can get authenticated into OKTA external tenant and get the token from the same tenant.

Step 2: Once the token is generated the session gets created into the external tenant itself and relay back to the app.

Internal user registrations steps:

Step 1: Users trying to login through the external applications.

Step 2: There is an IDP discovery happens based on the domain and it redirects to internal tenant through SAML.

Step 3: User found into the internal tenant group, then it does a delegated authentication to MS AD. AD confirms the identity of the user in the system and sends the confirmation back to the internal tenant.

Step 4: The Internal tenant sends the call back to external tenant with user session token or just a token to allow external tenant to generate its own session token.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

The below sections discussed about the external users login flow as well internal / employees login flow:

The above shows the data flow for employee/internal users (right hand side) which involved MS AD to authenticate user and provide SSO token.

On the left hand side you can find the external user login which is pretty straight forward. and involves only external tenant.

I hope this article will help you in understanding some aspects of OKTA architecture as well as how the user authentication and SSO works.