Explore our platform and learn how it can help your application shine.
Learn about modern authentication techniques and best practices.
Learn about access management practices and technologies.
Learn to manage user accounts and access at scale.
Understand multi-tenancy, a foundation of shared computing.
Learn how to design and build successful SaaS applications.
Understand what is required to provide an enterprise-ready product.
Understand the uses and benefits of Attribute-Based Access Control.
Learn how Single Sign On (SSO) can improve security and UX.
Learn about OpenID Connect, an open authentication protocol.
Learn about SAML, a popular SSO protocol.
Learn about our history, our team, and our mission.
OpenID Connect, also known as OIDC, is one the most commonly used authentication protocols in the SaaS space today. One of the biggest reasons for this widespread adoption is the seamless compatibility with web and mobile. The following article will show you how OIDC authentication works and also familiarize you with some industry best practices for best results.
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.
Now that we have covered how OpenID Connect works, lets learn about the main benefits of embracing this authentication and authorization methodology.
Security Assertion Markup Language (SAML) is a standard that allows identity providers and service providers (websites and apps) to exchange authentication and authorization data. It is an alternative to OIDC, which can also be used to implement SSO. SAML is complementary to OAuth – you can implement SAML with OAuth as the authorization layer. It is common to use OAuth with either OIDC or SAML.
For example, if you use OAuth to allow an app to access your Facebook account, the appacts as a consumer, while Facebook is the service provider. Facebook produces tokens, which the application can use to access your account data.
OpenID Connect is suitable for private users. If you use OIDC, you can first authenticate your account in another application. One common use case is Gmail. In this case, Google is your identity provider, and you can sign in to third-party applications via your Google account. If the third-party app is compromised, Google still stores credential data safely, so hackers cannot access it.
SAML is preferred for enterprise authentication. You can use SAML to allow internal users to log in to an organization’s network. Once users have logged in, they don’t have to re-enter their credentials to gain access to any app in the protected network.
Read More: OIDC vs OAuth2 | OIDC vs SAML
As mentioned earlier, OIDC is based on OAuth and simply extends its capabilities. OAuth was originally designed to enable delegated access, allowing a user to sign into one application and receive access to another application.
However, OAuth was limited. It did not provide a mechanism for transferring identifiable information about the user. OIDC adds this crucial functionality, complementing OAuth authorization with the ability to authenticate the user. Thus, OIDC makes it possible to give each user specific permissions in the delegated app. All leading SaaS applications today are using this methodology.
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).
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
3.3 / 5. 4
No reviews yet
