Understand IAM, OAuth, OpenID Connect, SAML, SSO, and JWT in one article

The domain of identity and access management (IAM) has grown more intricate over recent years. The fancy terms like OAuth, OpenID Connect (OIDC), SAML, SSO, and JWT are frequently used, but what do they mean? How do they work together? Let’s explore these concepts and frameworks to make them more understandable and practical.

What is IAM?#

Identity and access management (IAM) is a broad concept that involves managing digital identities and implementing access control. The frameworks and protocols mentioned earlier fall under IAM, each addressing specific challenges in this space.

In essence, IAM is about:

• Identity: A digital representation of a user, service, or device. An identity typically includes attributes such as name, email, roles, etc., to describe the entity.
• Access: The ability to interact with resources, perform actions, or use services. Access defines what actions can be performed on which resources.

In the diagram above, a user (identity) wants to perform a GET request on an API (resource). The user's attributes - name, email, and role - describe the identity.

Authentication vs. authorization#

Authentication and authorization often appear together in IAM discussions. Let’s clarify their definitions:

• Authentication: The process of verifying the ownership of an identity. It answers the question, "Which identity do you own?"
• Authorization: The process of determining what actions an authenticated identity can perform on a resource. It answers the question, “What can you do?”

In the earlier example:

• Before the user (identity) can perform any actions, they must complete the authentication process.
• After authentication, the system needs to determine if the user can perform a GET request (action) on the API (resource), i.e., complete the authorization process.

---

Armed with this foundational knowledge, let’s demystify the other acronyms and protocols.

OAuth#

OAuth 2.0, commonly referred to as OAuth, is an authorization framework that enables an application to access protected resources on another application (typically on behalf of a user).

For example, imagine you have a web application called MyApp that wants to access a user's Google Drive. Instead of asking the user to share their Google Drive credentials, MyApp can use OAuth 2.0 to request permission (authorization) from Google to access the user's Drive.

Here’s a simplified diagram illustrating the OAuth flow:

In this flow:

• MyApp is the client (identity) requesting access to Google Drive (resource).
• The user (resource owner) grants MyApp permission in step 6, completing the authorization process.

A key element in OAuth 2.0 is the access token, which the client uses to demonstrate the user’s authorization to access resources. To dive deeper, see Access token.

OpenID Connect (OIDC)#

OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0. It adds features specifically for authentication, such as ID tokens and a UserInfo endpoint, making it suitable for both authentication and authorization.

If we revisit the OAuth flow, adding OIDC introduces an ID token. This token contains information about the authenticated user and enables MyApp to verify the user’s identity.

Example scenario: "Sign in with Google"#

Let’s switch examples. If MyApp wants to allow users to sign in using their Google accounts, the goal shifts to authentication rather than resource access. In this case, OIDC is a better fit. Here’s how the OIDC flow looks:

Key Difference: In addition to an access token, OIDC provides an ID token, which allows MyApp to authenticate the user without requiring additional requests.

OIDC shares OAuth 2.0's grant definitions, ensuring compatibility and consistency across the two frameworks.

SAML#

Security Assertion Markup Language (SAML) is an XML-based framework for exchanging authentication and authorization data between parties. SAML, introduced in the early 2000s, has been widely adopted in enterprise environments.

How does SAML compare to OIDC?#

SAML and OIDC are functionally similar but differ in their implementation details:

• SAML: Uses XML-based assertions and is often considered more complex.
• OIDC: Leverages JSON and JWT, making it lighter and more developer-friendly.

Modern applications often prefer OIDC for its simplicity and flexibility, but SAML remains prevalent in legacy systems and enterprise use cases.

Single sign-on (SSO)#

Single sign-on (SSO) is an authentication scheme that enables users to access multiple applications and services with a single set of credentials. Instead of logging in to each application individually, the user logs in once and gains access to all connected systems.

How does SSO work?#

SSO relies on a central identity provider (IdP) to manage user identities. The IdP authenticates the user and provides services like authentication and authorization to connected applications.

The IdP can use protocols like OIDC, OAuth 2.0, SAML, or others to provide these services. A single IdP can support multiple protocols to meet the diverse needs of different applications.

Example of OIDC-Based SSO#

Let's explore an example of OIDC-based SSO:

In this flow, the user logs in to the IdP once and is authenticated across multiple applications (AppA and AppB).

Enterprise SSO#

While SSO is a broad concept, you may also encounter the term enterprise SSO, which refers to a specific type of SSO designed for enterprise environments (typically for employees and partners).

When a customer requests SSO for your application, it’s important to clarify their needs and the protocols they are using. In most cases, this means that for specific email domains, they want your application to redirect users to their IdP (which implements enterprise SSO) for authentication.

Example: Adding an Enterprise SSO provider#

Here’s a simplified example of integrating an enterprise SSO provider (Banana) with your application (MyApp):

JWT#

JSON Web Token (JWT) is an open standard defined in RFC 7519 that enables secure communication between two parties. It is the standard format for ID tokens in OIDC and is widely used for OAuth 2.0 access tokens.

Here are the key characteristics of JWT:

• Compact: JWTs are JSON objects encoded in a compact format, making them easy to transmit and store.
• Self-contained: JWTs contain all the necessary information about the user and the token itself.
• Verifiable and encryptable: JWTs can be signed and encrypted to ensure data integrity and confidentiality.

A typical JWT looks like this:

This JWT consists of three parts separated by dots:

• Header: Contains metadata about the token, such as the token type and signing algorithm.
• Payload: Contains information about the identity and the token itself.
• Signature: Verifies the token’s integrity.

Both the header and payload are base64-encoded JSON objects. The JWT above can be decoded as follows:

Using JWT, the client can decode the token and extract the user's information without making additional requests to the identity provider. To learn more about JWT, visit JSON Web Token (JWT).

Recap#

We’ve covered a lot of ground in this article. Let’s summarize the key points with an example:

Imagine you have a web application, AppA, that requires an identity and access management (IAM) solution. You choose Logto, an identity provider that uses OpenID Connect (OIDC) for authentication. Since OIDC is built on top of OAuth 2.0, Logto also supports authorization for your application.

To reduce friction for your users, you enable "Sign in with Google" in Logto. This uses OAuth 2.0 to exchange authorization data and user information between Logto and Google.

After the user logs into AppA via Logto, AppA receives an ID token, which is a JSON Web Token (JWT) containing the user’s information.

As your business grows, you launch a new application, AppB, which also needs user authentication. Since Logto is already set up, you can reuse the same authentication flow for AppB. Your users can now sign in to both AppA and AppB with a single set of credentials, a feature known as single sign-on (SSO).

Later, a business partner asks you to connect their enterprise SSO system, which uses Security Assertion Markup Language (SAML). You find that Logto supports SAML connections, so you set up a connection between Logto and the partner's SSO system. Now, users from the partner’s organization can also sign in to AppA and AppB using their existing credentials.

---

I hope this article has clarified these concepts for you. For more in-depth explanations and examples, check out Auth Wiki. If you’re searching for an IAM solution for your application, consider using a managed service like Logto to save time and effort.