The OpenID Connect (OIDC) authentication protocol lets you verify the identity of users attempting to gain access to endpoints protected by HTTPS. The OpenID Foundation (comprising companies such as Google and Microsoft) developed OIDC on the basis of the Open Authorization (OAuth) protocol. While OAuth provides only authorization, OIDC delivers an added layer of security through authentication.
This combination of authentication and authorization means you can use OIDC for single sign-on (SSO), which allows users to retain a single login across multiple websites or applications. SSO is very convenient for users, because it doesn’t force them to memorize and re-enter credentials to access different sites. OIDC is basically a next-gen user management technology, as it helps manage identities.
This is a part of an extensive series of guides about Access Management.
In this article:
In a traditional OAuth flow, the end-user provides their credentials to the identity provider. The user receives an authorization prompt, in which they allow the delegated app to reuse their login to the identity provider. OAuth then provides the application an Access Token, which authorizes the user to access the app, but does not contain any information about the user.
OIDC uses the same authorization prompt to authenticate the user and provide an ID Token. The ID Token is technically a JSON Web Token (JWT), and includes identifiable information about the user, such as their name and email address. The application can use this ID Token to prove users are authenticated.
OAuth uses the concept of tokens and scopes:
In the original OAuth standard, applications had to define scopes themselves, and there was no agreed standard for scopes. Because scopes could be different for each provider, it was difficult to integrate with multiple identity providers.
OIDC takes this one step further by providing the UserInfo Endpoint, which delivers information about the user, leveraging a set of standard scopes, while allowing customization. An OIDC ID Token includes the following basic claims:
Also, the ID Token provides apps with additional user data, which isn’t a part of the authentication process and is used for functional purposes. The ID Token can include names, emails, and more (see the full list of OIDC standard user claims). You can use standard OIDC scopes alongside regular OAuth scopes, so OIDC supports previous scopes developed by identity providers.
OIDC has discontinued the use of grants, and the OAuth Implicit Flow is deprecated as it’s insecure. OIDC uses the Proof Key for Code Exchange (PKCE) OAuth extension to prevent CSRF and authorization code injection attacks.
Here are some of the main OIDC flows.
You can use this flow for non-sensitive data and browser-based applications. It works by allowing authorization endpoints to request identity tokens directly (if necessary, they can also request OAuth access tokens).
Implicit flow is seen as a less secure option because the tokens are visible to the browser (as well as the code running in the browser). This significantly expands the attack surface. For this reason, you should only use implicit flow for tokens that do not contain any sensitive data or personally identifiable information (PII), or for number-only-used-once (nonce) validation.
This flow is useful for web-based apps that require backend communication with identity providers. It is a three-legged flow, which works by returning OAuth access tokens to the web app through backend calls. Instead of directly transmitting a user’s details, the provider sends one-time codes, which can be exchanged for OAuth access tokens, providing the app with the client ID and secret.
This is a secure flow because the browser cannot see the tokens, and the identity provider can authenticate the application.
This flow is mostly used for server-side apps. It works by allowing apps to request authorization codes from an authorization endpoint. These codes can be exchanged for identity tokens or OAuth access tokens as needed.
While the identity and access tokens are not exposed to the browser, refresh tokens can be used to enable actions on the behalf of a user (when the user is no longer present or is no longer active). For this reason, the authorization code flow should be strictly reserved for confidential clients, who can be relied upon to store the secrets safely. This flow needs to be planned carefully and monitored constantly.
You can use this flow for clients that must process authorization code before exchanging it for tokens or non-sensitive information. It works by letting authorization endpoints return authorization codes and tokens. Endpoints can perform code hash checks and nonce validation in advance, and client apps can use PKCE to prevent malicious injections of authorization code.
This option is not suitable for sensitive data because it exposes tokens to the browser. Like the authorization code flow, this flow enables actions to be performed on behalf of a user when offline. Limit it to confidential clients.
An OIDC Provider is a certified OpenID Provider library offering a secure authentication mechanism for Node.js apps and API security. It provides an authentication framework, rather than allowing you to mount and modify specific elements. However, it may not suit cases that require custom logic or grant types. The library is certified for all five OpenID conformance profiles.
Top public OpenID Connect providers today include Google, Microsoft, Amazon, PayPal, Yahoo, and Okta. Most of these options provide discovery metadata in JSON (with the exception of Amazon and Okta).
Now that we have covered how OpenID Connect works, lets learn about the main benefits of embracing this authentication and authorization methodology.
OAuth2 is primarily an authorization framework, which allows applications to obtain limited access to user accounts on an HTTP service. OAuth2 provides access tokens that can be used to access resources on behalf of a user. It does not, however, provide information about the user itself.
OIDC, built on top of OAuth2, adds an authentication layer, enabling the client to verify the identity of the end-user based on the authentication performed by an Authorization Server. OIDC provides ID Tokens, which contain user information and are used to prove that the user has been authenticated. This addition makes OIDC more suitable for Single Sign-On (SSO) scenarios compared to OAuth2 alone.
Security Assertion Markup Language (SAML) is an older protocol compared to OIDC, used primarily for Single Sign-On (SSO) in enterprise environments. SAML uses XML for message formatting and relies on browser redirects to transfer authentication information between the identity provider and the service provider.
OIDC, in contrast, uses JSON and a RESTful interface, making it more suitable for modern web applications and APIs. OIDC is simpler to implement than SAML and is designed to work seamlessly with both web and mobile applications. While SAML is robust and widely adopted in corporate environments, OIDC offers a more developer-friendly and flexible approach to authentication, especially for new applications.
Lightweight Directory Access Protocol (LDAP) is a protocol used to access and manage directory information services over a network. LDAP is primarily used for authentication and as a directory service in enterprise environments. It allows applications to interact with a centralized directory to retrieve user details and perform authentication.
OIDC is a web-based protocol that uses OAuth2 for authorization and adds an authentication layer. OIDC does not replace LDAP but can complement it. For example, an organization might use LDAP for internal authentication and OIDC for external applications and SSO. OIDC is more suitable for web and mobile applications that require a modern, standardized approach to authentication and authorization.
Kerberos is a network authentication protocol designed to provide strong authentication for client-server applications. It uses secret-key cryptography and requires a trusted third party, known as the Key Distribution Center (KDC), to authenticate users and services.
OIDC is more suited for web and mobile applications, offering a simpler implementation through its use of OAuth2 and JSON Web Tokens (JWT). Unlike Kerberos, which is typically used within a controlled enterprise network, OIDC is designed for use across the internet and supports a wide range of devices and platforms.
Kerberos provides a high level of security and is suitable for environments where internal security is critical. In contrast, OIDC offers greater flexibility and ease of integration for modern applications that require secure authentication across various platforms and devices.
Read More: OIDC vs OAuth2 | OIDC vs SAML
A Relying Party (RP) is an organization that uses OpenID Connect to enable users to authenticate through other identity providers. Here are some of the best practices recommended for RPs:
If you choose to implement the OpenID protocol yourself (instead of an established library), you’ll need to take extra precautions. Be aware of additional risks involved. For example, attackers can use XSRF to quietly sign a user into your website. This works by forcing checkid_immediate() requests to the OpenID provider through the relying party’s login page.
While the first 7 best practices were general recommendations, you you implement the following while implementing your own OpenID library:
With Frontegg, you can utilize OpenID Connect in 2 ways. Firstly, OIDC can be used as a Service-Provider, allowing end customers to federate identity to their IDPs using Open-ID connect protocol. Secondly, the Frontegg solution can act (via a hosted login) as an Identity Provider (IDP) by providing OIDC compliant authentication for customers to redirect their users to the hosted login.
OIDC is the new way of making multiple applications work in tandem with zero hiccups or technical issues. Want to add OIDC to your application? You can get started now with Frontegg, an end-to-end user management platform.
Start For Free
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of access management.
Authored by Frontegg
Authored by Faddom
Rate this post
5 / 5. 14
No reviews yet
