This content originally appeared on Level Up Coding - Medium and was authored by Jan Michelfeit
Name it to tame it. OIDC and OAuth inside.
Recently, I noticed I got confused when talking about our identity and access management solution. We constantly need to translate between vocabularies of our identity platform Okta, OAuth and OIDC standards, and our slang. The fact that Okta is sometimes using the same name for different concepts or a different name for the same concept is not helping either.
That’s why I came up with a disambiguating map of all important concepts in Okta, and show how they relate to OAuth 2.0 and OpenID Connect use cases. You name it, you tame it — hopefully no more confusions!
- We’ll start by going through important concepts grouped around Directory, Application, and Security. There will be a diagram for each with brief concept descriptions, an explanation of potential confusions, and links to documentation.
- Then we’ll have a look at how it all comes together — the grand scheme of things in a single picture.
- Finally, we’ll dig deeper into how Okta configuration relates to OpenID Connect SSO and OAuth 2.0 authorization.
This post is dense and is intended as reference material for the parts I find most useful. It is not aspiring to cover everything in all its complexity, nor create an introductory guide. The impatient can jump straight to the “Tying It All Together” section for the diagram I find the most valuable.
All the Building Blocks
Directory
Two key concepts are Users and Groups. Hopefully no ambiguity here (except that Users are also referred to as “People”). Users can be created manually, just-in-time, or imported. Groups can be also populated automatically according to Rules.
Another important concept is Profile. This is where the confusion starts. There is a Profile that defines attributes (names, types), and there is a corresponding profile (yellow in the diagram) associated with an entity (user, group, application, …) with actual values of these attributes. I will use the capitalization of the first letter to distinguish between these two.
There are several kinds of Profiles — for a User, Group, Application, Directory, or Identity Provider (IdP). They define what attributes can be edited or accessed for the corresponding profile of a concrete entity.
Where do profile values come from? Directory and IdP profiles are views over the data stored externally (e.g., in Active Directory). User profiles can either be edited manually or are filled in from a Profile Source (Directory or IdP). Group and Application profiles can be edited manually, though only through Okta API for the latter.
A Mapping determines how values between different profiles are transferred. E.g., when a user is created or updated, User profile attributes can be populated from a Profile Source profile according to a Mapping. It also works in the other direction when Okta needs to update an account in an external system.
Fun fact: an App Profile doesn’t correspond to an Application profile.
Wait, what 🤯?
In addition to an Okta User profile, all Users have a separate Application User profile (referred to as app profile or appuser) in the context of each assigned Application. App Profile defines attributes and mapping between the User profile and the Application User profile. Now, Application as represented in Okta also has its own profile. This is completely unrelated to a user, though, it’s just a bunch of values associated with the Application; these cannot even be edited in the UI, only through Okta API. The bottom line is that Application profile is related to an Application only, while App Profile and Application User profile (app profile) relate to a mapping between an Application and a User.
Confused? Now you know why I had the urge to write this post.
Applications
The next group of concepts is centered around Applications. If the first thing that jumps to mind is a backend service that receives tokens from a client, think again 🤔. Application in Okta is a thing that can request tokens. It is closer to a Client in OAuth 2 or Relying Party in OIDC.
An Application holds information about the protocol (flows, grant types) in which it wants Okta to communicate, credentials, users who can use the application, etc. The terms App or Application Integration are also used, the latter mostly in the context of pre-built (as opposed to custom) Applications.
Unfortunately, another ambiguity needs clarification. Okta is using the term application for a different concept as well — Profile Source:
A profile source is an application that acts as a source of truth for user profile attributes. A user can only be sourced by a single application or directory at a time.
From the context, I assume they actually mean an Identity Provider but perhaps there’s a hidden relation I haven’t figured out yet 🤷.
There are several flavors of Applications (App Integrations?) depending on what kind of interaction is intended — OIDC, SAML, … For machine-to-machine integrations, one can use an API Services Application.
Unless an Application is intended for machine-to-machine interactions, it has assignments to Users and Groups which determine which users can interact with the Application (e.g., be issued an identity token requested by it). The Application also has an App Sign-On Policy. Later we will talk about Okta Sign-On Policy which controls how users are allowed to sign in to Okta (e.g., MFA requirements). App Sign-On Policy can restrict this further for access to each Application (e.g., how often re-authentication is required).
Security
Our last group of concepts is located in Okta UI under Security.
The key concept is Authorization Server — an engine for minting OIDC identity tokens or OAuth 2.0 access/refresh tokens. It represents a security boundary, with its own signing keys, issuer URI, and audience (identifier of the final token recipient). There is a built-in Org Authorization Server for getting access to Okta itself, and a number of Custom Authorization Servers can be provisioned for custom applications.
A custom set of Scopes (access privileges requested during authorization) and Claims (statements about the token subject) can be defined for each Authorization Server.
All of this is tied together with Applications through Access Policies. They determine what Scopes can be requested by an application, token lifetimes. They can restrict grant types and users allowed to obtain tokens through the policy, i.e., a token can only be issued for a user if there exists an Access Policy allowing it under given conditions. Each policy can be assigned to one or more Applications (referred to by Okta as “clients” in this context 🤦).
Another concept is Identity Provider — a service managing user accounts that can be used as a source of Users and User profiles discussed earlier. Routing Rules control what IdP will a user be forwarded to under what circumstances.
Identity Providers serve as a source for the Okta instance users but note that Okta itself can serve as an identity provider for another system. This could even be another Okta instance! If a source Okta instance S provides identities for a target instance T, then T would be represented as a (e.g., SAML) Application in S, and S would be represented as an Identity Provider in T.
Okta Sign-On policy and Password policy control how users belonging to selected groups can sign-in to Okta. Other concepts in the Security section are beyond the scope of this post.
Tying It All Together
Here comes the grand scheme of things. I’ve highlighted the key concepts that bind all parts together: User/Group — Application — Access Policy — Authorization Server. All the concepts live in an Okta organization serving as an isolated container for the entities.
We can see the levers Okta provides for its different use cases:
- One piece of magic is maintaining the User Directory — apart from manually creating users and groups, they can be imported from Profile Sources (IdP or Directory), assigned to groups with Rules, and have their profiles populated according to Profile attribute definitions and Mappings.
- The second piece of magic is about delegated identity or access verification through identity and/or access tokens. Authorization Server issues tokens to clients represented by an Application according to Access Policies.
- The rest is concerned mostly with fine-grained control of access to Okta and applications.
Relation to OpenID Connect and OAuth
The use cases of delegated identity verification such as OIDC SSO, or delegated authorization with OAuth 2.0 deserve more detail. Here is a simplified portion of the relevant concepts:
A typical flow may look like this:
- A client (e.g., an OAuth client or OIDC relying party), represented in Okta as an Application, initiates a request for a token. It either acts on behalf of a User, or it can act on its own for machine-to-machine interactions. In the former case, the token can be issued only for Users assigned to the Application (directly or via Groups) and can be further restricted by App Sign-On Policy. Allowed flows (grant types) are determined by the Application, which also holds related credentials (e.g., client ID/secret).
- The token request is forwarded to an Authorization Server. It is granted only if allowed by an Access Policy. Access Policy also controls which Scopes, among those configured for the Authorization Server, can be requested.
- If allowed, a token is issued with the requested Scopes, attributes like audience and issuer (which are part of the Authorization Server configuration), and other Claims. Claims can come from different sources, such as the User’s profile, appuser profile, or Application profile.
- Finally, the token(s) get to the client (Application) which initiated the request. The client can use an identity token to verify User’s identity and profile information (e.g., for SSO purposes), or an access token to access protected resources. To validate the tokens, clients can use information (such as public keys) exposed by one of Authorization Server endpoints.
Conclusion
As you can see, there can be a lot of ambiguity. When someone says “application”, do they actually mean an OAuth client? Backend service? Okta App integration? Or perhaps even an Identity Provider?
When we cannot name things clearly, we lose the ability to think clearly about what we are building. On the other hand, naming things well and consistently create a shared understanding of purpose. I hope this post will help you build such understanding as it did for me.
PS: Would you like to see more concept maps? About what topics? I would like to hear from you!
Level Up Coding
Thanks for being a part of our community! Before you go:
- 👏 Clap for the story and follow the author 👉
- 📰 View more content in the Level Up Coding publication
- 🔔 Follow us: Twitter | LinkedIn | Newsletter
🚀👉 Top jobs for software engineers
The Ultimate Illustrated Reference of Okta Concepts was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Jan Michelfeit
Jan Michelfeit | Sciencx (2022-07-24T23:25:51+00:00) The Ultimate Illustrated Reference of Okta Concepts. Retrieved from https://www.scien.cx/2022/07/24/the-ultimate-illustrated-reference-of-okta-concepts/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.