Choosing from an array of authentication protocols can be daunting. But one standard that stands out in the crowd is OpenID Connect (OIDC), a relatively “young” creation of the OpenID Foundation that has taken the digital world by storm in recent years.
But what is OIDC exactly, how does it work, and who is it best for? This guide will help you get the answers to these questions and more.
What is OIDC?
OIDC, short for OpenID Connect, is an authentication layer built on top of the OAuth 2.0 open standard. It facilitates the exchange of user identity information between third-party IdPs and client applications, thus enabling authentication.
To securely transfer the user information between the IdP and the application, OIDC uses JSON Web Tokens (JWTs).
This standard is widely used for single sign-on (SSO) and identity federation, providing a seamless and secure login experience for the end users across multiple applications and services.
OIDC lets users log into different applications using just one set of login details from trusted providers like their email (Google) or social networks (Facebook). When using an application that supports OIDC, users are sent to their chosen provider to confirm their identity, then sent back to the site they were trying to access, ready to use it.
Let’s take a look at a real-world example of OIDC in action.
Imagine we’re trying to log in to Canva — the application allows users to identify themselves using different identity providers like Google and Facebook.
After selecting to continue with Google, the user is taken to the next screen where they are prompted to enter their credentials. This step can also be skipped if the user is already logged in to their Google account.
The final step is authorizing Google to share the necessary identity information with Canva, the client application. After this, the user is redirected to the application.
OAuth 2.0 vs OIDC
You may have heard OAuth 2.0 and OIDC being used interchangeably. However, it’s important to understand the difference and relationship between the two of them.
OAuth 2.0 (sometimes shortened as OAuth2) is an authorization framework that enables third-party applications to access protected resources on behalf of a user, without the user having to share their credentials. However, OAuth 2.0 doesn't inherently address user authentication.
OIDC was developed to bridge this gap. It uses OAuth2 as a baseline and adds a new token—the ID token—that includes user identity claims in JSON format.
In combination with OAuth 2.0, OIDC allows users to sign in to websites using pre-established credentials with IdPs (e.g. Google, Facebook, GitHub).
| OAuth 2.0 | OIDC |
|---|---|---|
Purpose | Authorization and access control | Authentication |
Tokens used | Access Token, Refresh Token | Access Token, Refresh Token, ID Token |
Relationship to each other | Can work on its own | Works on top of OAuth 2.0 |
Use cases | Governing access to app resources | Authenticating users, Single sign-on (SSO) |
Read more: OIDC vs SAML: Understanding the Differences
How does OIDC work
There are three key players in an OIDC flow:
The client or Relying Party (RP): An application or service that requests the user’s identity.
The OIDC Provider: The entity that performs the user authentication.
The end-user or Resource Owner: The individual or entity looking to access the application.
The OIDC authentication process typically follows these steps:
The end user attempts to access a protected resource.
The Relying Party redirects the end user to the OIDC provider for authentication.
The end user authenticates with the OIDC provider using their credentials.
The OIDC provider generates an ID token and sends it to the Relying Party.
The Relying Party verifies the ID token and grants the end user access to the protected resource.
OIDC flows
Similar to OAuth grants, OIDC flows can be performed through different methods, depending on the type of application and security considerations at play. Some methods include:
Authorization code: Instead of directly returning a token, the server presents the Relying Party with a single-use authorization code. This code is then exchanged for the required tokens. For single-page apps and mobile/native apps, this flow can be modified with PKCE (Proof Key for Code Exchange).
Implicit: This is a less secure flow than the authorization code method. Using this method the token is directly returned to the Relying Party in a redirect URL.
Hybrid: This method combines the implicit and authorization code flows. While the ID token is returned directly to the Relying Party, the access token is only returned after being exchanged for an authorization code.
Benefits of OIDC
OIDC is a secure, efficient, and user-friendly approach to managing digital identities. It facilitates better security practices and improves the experience for both users and developers.
Simplified authentication: OIDC streamlines the authentication process by enabling SSO across multiple applications. Users can authenticate once with their OpenID provider and access multiple services without re-entering their credentials.
Improved security: By centralizing the authentication process with a trusted provider, OIDC helps mitigate the risk of password-related breaches.
Enhanced privacy: OIDC allows users to maintain control over their personal information. They can choose which data to share with the applications, and can revoke access at any time.
Interoperability: OIDC supports various authentication methods and can be easily integrated into existing systems. It's also compatible with most mobile and desktop applications, making it a versatile solution for any kind of application.
Scalability: OIDC makes identity and access management (IAM) more scalable by offloading the responsibility of user authentication to external identity providers.
Is OIDC secure?
OIDC is designed with several security features, making it a secure protocol for authentication when implemented correctly. However, like any technology, its security strength heavily depends on how it is deployed and configured.
For instance, in June 2023 Descope disclosed an implementation flaw affecting both OAuth and OIDC that could allow attackers to perform full account takeover on any app that uses “Log in with Microsoft”.
Implementing OIDC
OIDC offers a standardized, flexible, and secure authentication mechanism that can address a wide range of authentication needs, making it a strong option for many contemporary application architectures and user management strategies, including:
SSO: OIDC is ideal for organizations looking to implement SSO across multiple internal and external applications
Third-party authentication: When applications want to simplify the login process for users, but also reduce the burden of managing user credentials.
Federated identity management: In scenarios where multiple organizations want to allow access to shared resources without sharing a common security domain.
A few things to consider before adopting OIDC:
Security requirements: Ensure that OIDC implementation complies with your application's security policies and requirements.
Integration capabilities: Check the feasibility of integrating OIDC with your existing system architecture and identity management workflows.
Provider dependence: Consider the implications of relying on third-party identity providers for critical authentication services, including potential service disruptions and privacy implications.
OIDC authentication with Descope
Want to add secure, frictionless OIDC authentication to your app without the heavy lifting of in-house building and maintenance? Descope can help. Our drag-and-drop workflows abstract away the complexity of authentication so that developers can spend more time building their core product.
Since Descope can act as an OIDC federated identity provider, it can handle authentication without you having to change your primary IdP or user store.
Some use cases of implementing Descope as an OIDC provider are:
Adding passwordless authentication like passkeys to your existing logins on Amazon Cognito, Auth0, and Firebase.
Unifying user identities across several customer-facing apps and IdPs.
Using Descope authentication with server-side rendering (SSR) frameworks such as Next.js, Nuxt.js, and SvelteKit.
Sign up for our “Free Forever” tier today and begin your OIDC journey! Have questions about our product? Book a demo with our auth experts to learn more.
