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.
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.
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.
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.
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.
Similar to other SSO solutions, utilizing OIDC has the following benefits:
OIDC is unique because:
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:
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:
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.
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.
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.
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.
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.
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.
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.
SAML and OIDC are both powerful authentication protocols used to create secure sign-on experiences, but are used for different purposes.
Additional differences include:
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:
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.
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.
OIDC is an open standard, decentralized authentication protocol that allows websites and authentication services to securely exchange information in a standardized way.
It is easy, reliable, secure, and eliminates storing and managing people’s passwords. It improves the user experience of sign-up and registration and reduces website abandonment. Furthermore, Public-key-encryption-based authentication frameworks like OpenID Connect increase the security of the whole Internet by putting the responsibility for user identity verification in the hands of the most expert service providers.
Developers should use OIDC if they support mobile applications, access to APIs, and browser-based applications.
OpenID Connect has many architectural similarities to OpenID 2.0, and in fact the protocols solve a very similar set of problems. However, OpenID 2.0 used XML and a custom message signature scheme that in practice sometimes proved difficult for developers to get right, with the effect that OpenID 2.0 implementations would sometimes mysteriously refuse to interoperate. OAuth 2.0, the substrate for OpenID Connect, outsources the necessary encryption to the Web’s built-in TLS (also called HTTPS or SSL) infrastructure, which is universally implemented on both client and server platforms. OpenID Connect uses standard JSON Web Token (JWT) data structures when signatures are required. This makes OpenID Connect dramatically easier for developers to implement, and in practice has resulted in much better interoperability.
The primary difference between these standards is that OAuth 2.0 is an authorization framework used to protect specific resources, such as applications or sets of files, while OIDC is an authentication protocol used to create secure sign-on experiences. OIDC is about who someone is, whereas OAuth 2.0 is about what they are allowed to do when they access the resource.
The FIDO Alliance is one organization in which non-password authentication technologies are being explored. Some OpenID Foundation members are also members of the FIDO Alliance, working on authentication technologies there that can be used by OpenID Providers.
The FIDO Alliance is an open industry association focused on creating authentication standards that “help reduce the world’s over-reliance on passwords.” Some OIDC Foundation members are also members of the FIDO Alliance, who are working on authentication technologies that can be used by OpenID Providers.
OpenID Connect identifies a set of personal attributes that can be exchanged between OPs and the apps that use them and includes an approval step (aka authorization) so that users can consent (or deny) the sharing of this information.
Since tokens are used to authenticate users instead of usernames and passwords, users don’t need to share their credentials with any of the applications they access.
Start Today
Contact Sales
See how Ping can help you deliver secure employee and customer experiences in a rapidly evolving digital world.
Request a FREE Demo