What is OpenID Connect (OIDC)?

Welcome back to B2B Auth School. Our mission is to help B2B companies’ uplevel their understanding and implementation of user authentication technologies. Our first series of posts is dedicated to single sign on (SSO). This article is lesson five in that series.

In the previous lesson we looked at the importance of single sign on protocols – what they are, how they’re created, and why they’re important for B2B Auth. We then went over the two most common protocols in single sign on: Secure Assertion Markup Language (SAML) and OpenID Connect (OIDC).

In this post, we’re going to look more closely at OpenID Connect to understand how it works, and get a more nuanced understanding of its benefits, drawbacks, and most common use cases. We’ll cover:

What are OAuth and OpenID Connect
The components of OpenID Connect
How OIDC works in three phases
What OIDC means for B2B auth

Now that we’ve got that straightened out, let’s dive in!

What are OAuth and OpenID Connect?

As we mentioned in our last post, OpenID Connect is an authentication layer built on top of an authorization protocol called OAuth. Because of their symbiotic relationship, the two protocols are often used interchangeably by developers; but to be precise, OAuth is for authorization and OpenID Connect is for user authentication.

Authorization verifies what a user is allowed to access.

Authentication> verifies who a user is and their identity.

The two protocols are, so to speak, two sides of the same coin. To understand how OIDC functions as an SSO protocol, we need to cover the fundamental aspects of OAuth’s design because it was created first.

OAuth was jointly developed in 2006 by Twitter and Google. With near universal adoption of social media sites, developers realized that their applications would greatly benefit from letting users bring in their data from accounts like Facebook, Twitter, or Google. This linking of accounts has proven to be a powerful integration pattern. Users bring their data over to an application for convenience while developers build features on top of it.

You’re probably most familiar with OAuth with social accounts. If you’ve ever authorized an app to access the resources in your Gmail or Facebook account, you’ve used OAuth. Examples of these authorization prompts look like:

“Allow this app to add all your Facebook friends as contacts?”
“Allow this app to post links on your Twitter feed?”
“Allow this app to sync events with your Google Calendar?”
“Allow this app to use your profile picture from Gmail?”

If the user consents, the application can then access the user’s data and resources as if acting on the user’s behalf. This pattern of granting permissions is known as delegated access or delegated authority.

In order to do this safely, OAuth lets users provide access to their accounts without exposing their login credentials. It’s a protocol that delegates access and permissions between APIs and applications in a safe and reliable exchange.

We’ll cover how this all works under the hood in a later section.

So why do we need OpenID Connect?

The short answer is OAuth only really cares about access to resources. Once a user grants permissions, the OAuth protocol interprets that as a green light for data access but stops short of actually verifying the identity of the user. OAuth confirms the user’s ownership of an account and its data, but omits the details about who the user is. It’s a subtle but important distinction.

OAuth simply doesn’t provide enough assurance that the right resources are only accessible by the right people. Because these gaps limit OAuth’s ability to serve some of the most crucial needs in B2B auth, OpenID Connect was added and launched in 2014 to treat federated identity as a first-class concept within the OAuth protocol. OpenID Connect introduces a standardized implementation, set of scopes, and data format for exchanging information about the user’s identity.

In this way, OAuth is a bit like sharing the key to your apartment. The key does not provide any assurance or verification of who is using it: anyone with the key can get in. This may work great for your dog walker or a neighbor you trust, but there are other kinds of assets you want to make sure only you can see. OIDC is more like the reception desk: in order to get in the building, one must prove who they are first by providing something like an ID, passport, or a list of personal details like name, birthday, and phone number.

OIDC administers the identity logic necessary for proper authentication. It generates a proof of an identity for the user that applications can store and verify. And by piggybacking off the OAuth architecture, OIDC utilizes the same secure mechanisms to transport that identity data between applications, which means OIDC is a form of delegated authentication.

OAuth and OIDC work great together because they are so interwoven. But most crucially, their design of delegated access and authentication creates interoperable interfaces necessary for organization-based authentication flows like SSO to function.

In the world of B2B Auth, both the authorization and authentication process are critical, as B2B customers want fairly granular control over who can access what.

The OIDC components

It’s helpful to lay the groundwork with some key terms and flows. There are hundreds of terms listed in the OAuth spec and OIDC spec, and we encourage anyone interested in a deeper dive to take a look at those resources. In this article, we’ll just focus on the main terms developers need to know in order to evaluate different SSO solutions for their application.

Like SSO, OAuth and OIDC can be broken down into a few main components. These are similar and mostly analogous to the components involved in single sign on.

Key components

The resource owner is the user authorizing access to a given resource. Because the user owns their data and the account, they are the one to initiate the entire OAuth process by granting access. In SSO, the resource owner would be the customer, or more specifically, a member of a B2B customer’s organization like an employee.
The relying party or the client is the application requesting permission to access the resource owner’s data or identity. In SSO, the client would be called the service provider or the B2B SaaS app.
The authorization server is the server that grants authorization after it verifies the resource owner’s account ownership – usually by logging in. It is also responsible for getting the resource owner’s explicit approval for the relying party to access their data and resources. In SSO, the authorization server is the identity provider.
The resource server is where the user’s resources and data are stored. In SSO, the resource server has no direct counterpart since it doesn’t affect identity. But because the authorization server and resource server are typically owned by the same party and sometimes are the same exact server, we can think of the identity provider also playing the role of resource server.

From a high level, the OIDC components should closely resemble the SSO components we covered in lesson three on SSO auth flows.

How does OIDC work?

OAuth is a deep and complex protocol if you explore every facet of it. To best understand its most important functions, and how it matters to SSO, it helps to analyze the protocol in three phases of action.

Phase one: a secure connection

A user initiates the OpenID Connect flow by choosing a third-party platform, such as Google or Facebook, to login with on a client application. The first phase involves the client application and the authorization server establishing a secure connection to prevent man-in-the-middle attacks and other security threats.

The client application can select several grant types to prove to the authorization server their connection is secure. The most secure is proof keys for code exchange (PKCE). You’ll also hear some OAuth literature discuss implicit and password grant types, but these are considered legacy practices and not recommended today because of various security concerns.

Using PKCE with OIDC adds an extra layer of security to the OAuth 2.0 authorization process by ensuring that any sensitive data is only sent to the original server that initiated the authentication request, and not to any other servers that may try to impersonate that server.

The client application generates a secret code, the code_verifier, and a hashed version of that code, the code_challenge.
The client application sends the code_challenge to the authorization server along with the authorization request.
The authorization server stores the code_challenge for a later phase.

Phase two: user login and consent

The authorization server prompts the user to log in to their third-party platform and to give consent to grant the client application access to their data. These actions are completely done in the UI by the user.

Once the authorization server confirms the user has logged in successfully, it resumes the PKCE code flow from phase one and generates an authorization code. The client application then sends both the authorization code and the original code_verifier back to the authorization server to verify against the code_challenge, thus proving the client application’s authorization request hasn’t been intercepted.

With the PKCE code flow completed, the client application can finally request what it needs most: tokens.

Phase three: bearer tokens

The OAuth and OIDC protocols use bearer tokens to transport access controls and data between the components. The name bearer token can be understood as “give access to the bearer of this token.” These tokens are encrypted pieces of data, like a JSON Web Token (JWT), that act as the main mechanism for delegated access and user authentication.

The main difference between OAuth and OIDC is the type of bearer token the client application requests from the authorization server. The types of tokens are:

An access token (OAuth) is used by the client application to access a given resource from the resource server. An access token is primarily used for authorization.
An ID token (OIDC) is used by the client application as a proof of identity for the user. Unlike an access token, an ID token is primarily used for authentication.
A refresh token is used by the client application to request either a new access token or ID token after they expire.

Once the authorization issues an access token or ID token, the client application has everything it needs for delegated access and authentication. The ID token confirms the user’s identity is genuine and the client application can consider the user fully authenticated via OIDC.

The full OIDC flow

OIDC for B2B auth

The OpenID Connect protocol is a deep and still evolving authentication framework boosted by OAuth’s architecture. Not only does the OIDC protocol fulfill the requirements for SSO login, but it is also designed for modern API support, mobile applications, and to handle the scale of social media platforms. It is a protocol well suited to support the diversity of both B2C and B2B auth models.

If you’re building SSO, OIDC is a future-forward path to create a robust and complex B2B auth solution. There is a lot more to the OIDC spec, but what we covered should give you a strong foundation of how the delegated authentication pattern works for SSO.

For our next lesson, we’ll be doing a tour of the SAML protocol.

See you then.