OpenID Connect (OIDC)

What is OIDC?

OpenID Connect (OIDC) is an open authentication protocol that works on top of the OAuth 2.0 framework. Targeted toward consumers, OIDC allows individuals to use single sign-on (SSO) to access applications (relying parties or RPs) using OpenID Providers (OPs), such as an email provider or social network, to authenticate their identities. It provides the application or service with information about the user, the context of their authentication, and access to their profile information.

The purpose of OIDC is for users to provide one set of credentials to access multiple sites. Each time users sign on to an application or service using OIDC, they are redirected to their OP, where they authenticate and are then redirected back to the application or service.

OIDC was designed to protect browser-based applications, APIs, and mobile native applications. It delegates user authentication to the service provider that hosts the user account and authorizes third-party applications to access the user’s information.

OIDC example

For example, there are currently two ways of creating a Spotify account. You can register with Spotify or you can sign on through Facebook or Google. These OPs then send an ID token containing your information, like your name and email address, to Spotify, which uses the token to validate your identity.

What are the benefits of OIDC?

No more managing passwords

OIDC enables organizations to provide a SSO experience, minimizing the time spent on signing in and remembering passwords, which in turn creates a smoother overall user experience with less friction. For example, many customers abandon their carts when shopping online due to forgotten passwords, but SSO offers a simpler, frustration-free process, leading to increased customer loyalty, higher conversion rates, and greater brand visibility.

Higher security

OIDC’s SSO capabilities significantly decrease the likelihood of a password-related hack. With SSO, users only need to remember a single password for all their applications and are less likely to reuse passwords or write them down, which reduces the risk of theft. Easy access is particularly valuable for employees that are in the field or working from multiple devices.

Improved user experience

This solution can also decrease IT costs by reducing the number of required passwords to just one, and can also be used to strengthen B2B partnerships. Using federated SSO (or federated identity management) via OIDC can help separate organizations and third parties, such as application vendors or partners, while also sharing identities and authenticating users across domains. When two domains are federated, a user can authenticate to one domain and then access resources in the other domain without having to sign on again.

Why Would You Use OIDC?

Similar to other SSO solutions, utilizing OIDC has the following benefits:

• Enables seamless SSO across multiple applications and services, which creates a more seamless user experience.
  
  
• Allows organizations to more effectively manage the user information of their customers, free users, and/or employees.
  
  
• Significantly decreases the likelihood of password-related hacks, improving security without impacting the user journey.
  
  

OIDC is unique because:

• It’s an industry standard widely available across a diverse range of platforms, including popular email providers and social media networks.
  
  
• It is built on top of the OAuth 2.0 protocol, adding user authentication and identity management. OIDC flows can get an access token, useful if you are also using APIs.
  
  
• It more confidently verifies who’s giving authorization to access protected resources.

How does OIDC work?

An OIDC solution enables the OP to determine the available authentication methods when users sign in. They may also request user consent to share identity information with the relying party.  Additionally, the OP can offer a range of authentication options, including:

• Passwordless, including FIDO passkeys
• One-time passwords (OTPs)
• App-generated codes
• Biometric factors, including fingerprint or facial recognition
• Federated login, including enterprise SSO or third-party OPs

The relying party can influence the OP’s authentication process, such as requiring multi-factor authentication (MFA). However, the specific way the OPs handle user authentication falls outside the scope of the OIDC protocol.

Since OICD is built on top of OAuth 2.0, it benefits from OAuth 2.0's well-established framework, which securely grants access to resources without exposing user credentials. OAuth 2.0 handles authorization (what data or resources can be accessed), while OIDC adds authentication (ensuring the user is who they say they are). OIDC is similar to OAuth 2.0 in the sense that users give one application permission to access data or resources in another application without having to provide their usernames and passwords. Instead, tokens are used to complete both authentication and authorization processes:

• Identity tokens, intended to be read by the client, prove that users were authenticated and are JSON Web Tokens (JWTs), pronounced “jots.” These files contain information about the user, such as their usernames, when they attempted to sign on to the application or service, and the length of time they are allowed to access the online resources.
  
  
• Access tokens are used to access protected resources, which are intended to be read and validated by the API. These tokens can be JWTs, but might be in a different format. Their purpose is to inform the API that the bearer of this token has been authorized to access the API and perform specific actions (as specified by the scope that has been granted).

ID tokens cannot be used for API access purposes and access tokens cannot be used for authentication. The following diagram shows how a typical OIDC authentication process works.

OpenID Connect Flows

It's crucial to understand the different OIDC flows to ensure you choose the right authentication method for your application, keeping security, user experience, and compliance in mind. Since OIDC has discontinued the use of grants and the OAuth 2.0 Implicit Flow has been deprecated due to insecurity, OIDC now emphasizes stronger options, such as the Proof Key for Code Exchange (PKCE), which helps prevent Cross-Site Request Forgery (CSRF) and authorization code injection attacks.

OIDC Authentication Flow

This method is commonly used for web applications requiring secure backend communication with identity providers. It operates by using a three-step process, where one-time authorization codes are sent instead of user details. These codes are then exchanged for OAuth 2.0 access tokens, allowing the app to securely authenticate with its client ID and secret. This method ensures the browser doesn't have direct access to the tokens, enhancing security while allowing the identity provider to confirm the app’s legitimacy.

OIDC Authorization Code Flow

This flow is commonly used for server-side applications. It operates by having apps request authorization codes from an authorization endpoint, which can then be exchanged for identity tokens or OAuth 2.0 access tokens as needed. Client apps can also use PKCE to prevent unauthorized code injections.

Since identity and access tokens aren’t exposed to the browser, refresh tokens can be leveraged to perform actions on behalf of the user even when they’re no longer active. This flow is intended for clients that can securely maintain a “client secret”, a confidential key or password used in OAuth 2.0, between themselves and the authorization server. Careful planning and continuous monitoring are crucial to ensure its security.

OIDC Hybrid Flow

Designed for clients that need to process an authorization code before exchanging it for tokens or non-sensitive data, this flow allows authorization endpoints to return both authorization codes and tokens, with nonce validation and code hash checks performed during the process to ensure integrity. Client apps can also use PKCE to prevent unauthorized code injections.

Although this flow offers flexibility, it’s not suitable for sensitive data due to the exposure of tokens to the browser. Like the authorization code flow, it enables offline actions on behalf of users, making it best for confidential clients that can manage security effectively.

OIDC Implicit Flow

Designed for non-sensitive data and browser-based applications, it enables authorization endpoints to request identity tokens directly, with the option to request OAuth 2.0 access tokens when needed.

However, the flow is seen as a less secure option because the tokens are exposed to the browser and its underlying code. This significantly expands the attack surface, so use should be reserved for tokens that do not contain any sensitive data , including personally identifiable information (PII) and for number-only-used-once (nonce) validation.

It’s important to note the OAuth 2.0 Security Best Current Practices discourage using the implicit flow due to security concerns, and it is largely deprecated in favor of more secure options like the Authorization Code Flow with PKCE.

Differences between SAML, OAuth 2.0, OpenID Connect

OpenID Connect vs OAuth 2.0

OAuth 2.0 is an open standard framework for API authorization. It defines how an API client can obtain security tokens that contain a set of permissions against the resources available through that API.

Instead of requiring a user to share login credentials with one application to give that application access to another, OAuth 2.0 delegates authorization decisions to a separate authorization server that hosts the user account. Essentially, OAuth 2.0 acts on behalf of the user, providing delegated access to a third-party service without the user exposing their credentials to that third party.

The primary difference is that OAuth 2.0 is an authorization framework used to protect resources, while OIDC is an authentication protocol layered on top of OAuth 2.0 to handle user sign-on. SAML, on the other hand, is a federated identity standard that addresses both authentication and authorization.

What is the difference between SAML and OIDC?

SAML and OIDC are both powerful authentication protocols used to create secure sign-on experiences, but are used for different purposes.

• SAML is an older standard and more widely adopted in enterprises that use web-based applications, while OIDC is newer and gaining traction with mobile and native applications.
  
  
• SAML is primarily used for browser-based applications and can be used on mobile devices through browser-based SSO, though it does not natively support API access. OAuth 2.0 provides API access and OIDC provides access to APIs, mobile native applications, and browser-based applications.
  
  
• OIDC can use public, third-party OPs, such as Google and Microsoft, or private OPs in enterprise environments to authenticate users. With OIDC, a user can gain access to an application by signing on with a trusted, OIDC-compatible account.
  
  
• For large enterprises that require a higher level of security, SAML might be the better choice. SAML allows multi-factor authentication, is feature-rich, and has been a staple for enterprise security for more than a decade.
  
  
• SAML is known for its flexibility, but most developers find OIDC to be less complicated.
  
  
• SAML uses tokens written in XML and OIDC uses JWTs, which are portable and support a range of signature and encryption algorithms.
  
  

Additional differences include:

• SAML is known for its flexibility, but most developers find OIDC easier to use because it is less complex.
  
  
• SAML is used to access browser-based applications and does not support SSO for mobile devices or provide API access. OAuth 2.0 provides API access and OIDC provides access to APIs, mobile native applications, and browser-based applications.
  
  
• OIDC is about who someone is. OAuth 2.0 is about what they are allowed to do.
  
  
• SAML uses tokens written in XML and OIDC uses JWTs, which are portable and support a range of signature and encryption algorithms.
  
  

Benefits of OIDC for Developers

OIDC is one of the newest security standards available and is used by developers who support mobile applications, APIs, and browser-based applications. Other benefits include:

No More Managing Passwords

Since tokens are used to complete the authentication and authorization processes instead of usernames and passwords, developers are no longer responsible for setting, storing, and managing passwords, which is often the cause of credential-based data breaches.

Higher Security

Using tokens makes it a highly secure protocol. Not only are user credentials not shared, but it also makes it possible for users to sign on to multiple applications without having to create separate usernames and passwords for each, which can easily be compromised.

Ease of Implementation

OIDC is an open standard, decentralized authentication protocol that allows websites and authentication services to securely exchange information in a standardized way.