IAM reference architecture with Okta

Authentication / Authorization overview

IAM stands for Identity Access Management. The primary purpose of any IAM tool is access management, which is usually associated with Authentication and Authorization.
In this article we’ll consider typical IAM reference architecture with Okta, Authentication and Authorization flow in few simple diagrams for the most wide-spread rich-client web application case. Authentication and Authorization mechanisms frequently seem complex to majority of developers, but in reality, they appear pretty simple, if you decouple them into few simple diagrams.

Let’s further refer to the component, which will be responsible for Authentication (and possibly Authorization) as a Security Gateway.

It’s a widely used approach to enforce Authorization within an Api Gateway, if it exists within the system / platform, or introduce it otherwise (the component will act as a Proxy for all calls to other back-end components and micro-services).
Alternativey, authorization could be implemented within each particular micro-service, based on verifying claims / authorities, stored in a user token (JWT, which stands for Json Web Token).

In this article we assume Authentication and Authorization will be performed by a 3-rd party Identity Access Management (further referred to as IAM) tool, e.g. Okta, which is one of the most mature enterprise-grade IAM tools and has convenient web interface for administering Users, Roles, Groups and their authorities (accesses).

Why would you bother with an enterprise-grade IAM solution? In long term, you will need to handle Authentication, Authorization, SSO, most probably LDAP integration etc within your platform. Would you want to implement a home-grown solution for that? It all depends on timeline, planned number of users, business model and revenue.

Why would you consider Okta, if you have an open-source alternative, like e.g. KeyCloak. Well, it’s pretty simple. Okta is a cloud-based, provided as a managed service with all the pros and cons (it’s paid, subscription-based service, but has good support), meanwhile Key Cloak is an Open-Source tool.
Keycloak can be deployed to either on-premise infrastructure, in a cloud, or even hybrid deployment model.
Keycloak usage assumes relying on community-driven support model.
Some specific compliance requirements could drive into opting out Keycloak as an Identity provider

Criteria	Okta	Keycloak
Pricing model	Open Source	Managed Service with subscription-based pricing model, with different pricing plans available based on the number of users and required features
Deployment model	Cloud-based, exposed as a managed service	Can be deployed to either on-premise infrastructure, in a cloud, or even hybrid deployment model
Dev support	Has dedicated Support team, which handles requests in accordance with declared SLAs	Community-driven support
Maintenance	When using a managed service, you don’t have to bother with it’s health Monitoring and maintenance	Your organization will be responsible for Keycloak maintenance
Data residency	Okta fulfills CCPA and GDPR acts & regulatory policies	It’s completely up to you, where Data will be stored
Connectors and adpaters	Okta suggests wide range of pre-built connectors for integration with popular applications and services	Keycloak deprecated supporting adapters as of 2022, instead Keycloak conforms to OAuth 2.0 and OIDC specification /standards, which allows great extension / integration capabilities
AD (Active Directory) integration (for importing existing users & groups into IAM tool)	Supports	Supports

The above component diagram is pretty self-descriptive.
The diagram illustrates Authentication process, which implies obtaining a Token (JWT).
Authorization and checking user token authenticity can be performed on security-gateway side, or within each micro-service side.
Authorization on each micro-service side is generally more secure, but would necessitate appropriate security checks (and probably IAM tool integration) on each service side. Instead, you could implement Authorization on security-gateway side, and check within each particular micro-service an appropriate claim (e.g. userId or token expiration) with some simple JWT library.

“Obtain Access Token” part includes Authentication,
“Verify Acess Token” covers Authorization.

So using particular IAM tool depends on your particular functional and non-functional (like e.g. compliance) requirements. And decoupling a complex flow into Component and Sequence diagram(s) would leverage the flow understanding by all involved into project stakeholders, either business analyst (BA), Software Engineers (developers), or Quality Assurance (QA) engineer.