OpenID Connect (OIDC) is a popular authentication protocol that powers seamless sign-up/sign-in flows across many modern apps and websites. However, there is a ton of fragmented documentation regarding its usage online, which may easily bewilder and overwhelm developers just getting started with it. The following two-part article provides a soft but detailed introduction to OpenID Connect and explains how to incorporate it into your backend flow for user authentication.

The Old Way

If you have ever worked on the back end of an app or website, you have probably encountered the sign-up and login features for authenticating users. Many implementations of this feature in the past and even now have simply used sign-up forms and databases, e.g., MySQL, to collect and store user information and credentials, i.e., username, password, email address, etc.

This approach works. It’s simple, but it has limitations. People have short attention spans because of information overload on social media. They consider it a hassle to fill out sign-up forms and may abandon your app or website if the signup process is too long.

There is also sign-up/sign-in fatigue. The average person on the internet has multiple logins for the many apps they use and websites they visit. The additional burden of having to figure out and constantly remember usernames and passwords for sign-ups and login-ins on your app/ site is one they would rather avoid.

Let’s also consider the possibility of hack attempts too. Storing user data in your managed databases puts it at risk of hacking attempts like ransomware, where hackers can cause havoc if they have your user logins.

Identity Provider Platforms to the rescue 🚒

One of the more sophisticated approaches modern businesses employ to address these limitations and more is the use of an identity provider service.

An identity provider service(IdP) is a platform that creates, stores, and manages user identities (usernames, passwords, etc.). Simply put, IdP providers already have your user data and use it to offer user authentication as a service. So just like how you can pay to use AWS or Microsoft Azure server infrastructure for hosting apps; you can similarly pay IdPs like Google and Twitter to verify users for your app/website instead of the users filling out a sign-up form.

You have already experienced IdP usage if you recently signed up or signed in to Spotify or another app using your Google/Gmail credentials. The IdP here is Google Sign-In, and the client app is Spotify. This sign-up style uses two handy features. Bring Your Own Identity (BYOI) and SSO(Single sign-on). With BYOI and SSO, users maintain one set of credentials and can sign up on an app using their profile information (email and password) from Google’s Gmail, Outlook, Facebook, etc., instead of creating new ones.

These features significantly improve the sign-up experience of users. They no longer need to remember passwords and usernames. Developers are also relieved of the burden of storing and managing user logins. In summary, IdPs provide access to your user profile data without adding to your workload.

The bridge between your application backend and identity provider services: OpenID Connect

For the backend of an app to communicate with an IdP for user authentication, there are specific protocols and standards they both have to implement, and that's where OpenID Connect(OIDC) comes into play. OpenID Connect is the middleman that powers the interaction between IdPs and apps and will be the main focus of the remainder of this article.

OpenID Connect (OIDC) is a protocol that allows developers to authenticate their users with IdPs. It lets them do this without owning and managing password files. On a side note, a protocol is a working set of rules and specifications to make something happen. In this scenario, the OIDC protocol provides a framework for the communication that must take place between the IdP and your app. Aside from being a protocol, OIDC is also a simple identity layer API built on top of the OAuth 2.0 protocol. It extends the features of OAuth 2.0 that enable a mobile app/website to redirect a user to an identity provider (IdP) for authentication and allows the user to authorize the release of their information.

To summarize, The OpenID foundation– the protocol founders–introduced OpenID Connect to help developers authenticate their users across websites and apps without owning and managing password files. The IdPs now own these files and use the OIDC protocol to offer user authentication to developers as a service. If you’ve used your Google credentials to sign in to applications like YouTube or used Facebook to log into Instagram, you have encountered OIDC in action behind the scenes.

3 Reasons why Developers use OpenID Connect(OIDC)

1. Readable JSON Format-OIDC is simple yet secure enough to integrate with web and mobile apps. It uses JSON which makes data interchange simple and transparent.

2. Standardization- OIDC is a standard protocol that can work with any application. It encodes user identity information in a JWT(JSON web token) called an ID token. JWTs are elegant and portable to use and integrate seamlessly with many applications.

3. API-Ready – Built on OAuth, which provides robust API access. OIDC provides additional data to enable the client to see who has logged in and with what level of access, something that makes user management easier.

OpenID Connect vs. SAML

OpenID Connect is not the first protocol to be used for authentication online. Once upon a time, before OIDC, there was SAML. SAML stands for Security assertion markup language and is an XML-based standard/identity protocol designed to authenticate users and provide identity data for access control.

It's a mature, feature-rich standard dating from 2005 and is still widely used by enterprises for SSO operations on corporate intranets and some websites. You have more than likely experienced SAML authentication in action in your work environment. For example, it enables you to log into your corporate intranet to access numerous additional services, such as Salesforce, Box, or Workday, without re-entering your credentials.

One interesting thing to note is that OIDC is a rewrite of SAML using OAuth2.0, but some people prefer SAML because it currently has more security features than OIDC. But generally, OIDC is preferred because of its usability and simplicity. It's considered an improvement of SAML based on lessons learned over the years for these reasons.

OpenID Connect vs. OpenID 1.0 and 2.0

OpenID 1.0 and 2.0 are earlier versions of the OpenID protocol that preceded OpenID Connect. These two had most of the features of OIDC but were deprecated because they were not API and mobile-app friendly. Today when ‘OpenID’is mentioned, it almost always refers to OpenID Connect rather than the earlier iterations.

OAuth 2.0 and OpenID Connect - A misunderstood relationship

OAuth 2.0 is most certainly something you've come across if you've ever downloaded a new app and given your consent to have it automatically source contacts from Facebook or your phone. OAuth 2.0 stands for "Open Authorization" and is an access delegation protocol designed to allow a website or application to access resources(eg. contacts, photos, etc) hosted by another app on behalf of a user without having them enter their credentials. It replaced OAuth 1.0 in 2012 and is now the de facto industry standard for online authorization. You can read more about OAuth 2.0 here.

OAuth 2.0 resembles the OpenID Connect protocol, don't you think? (At least the portion when users grant access without needing to enter credentials). This is because, as I mentioned earlier, a great deal of OIDCs implementation and flow extend OAuth 2.0 specifications, but that is as far as their relationship goes.

OpenID Connect and OAuth2.0 (Authorisation vs. Authentication)

There’s usually a temptation to mix up OAuth2.0 and OIDC because of their relationship. Many people use them interchangeably when talking about online authentication because OIDC is based on OAuth2.0. But they are distinct protocols and do different things.

OAuth2.0 is a protocol for authorization, not authentication. It grants permission to third-party apps to access specific resources on behalf of users, and it does this using a piece of data called an access token which contains user permissions and other vital information. The OAuth process usually includes several kinds of authentication in its flow, which is where the confusion usually comes in. The fact that OAuth2.0 has authentication steps does not make it an authentication protocol. Organizations can however use it for building an authentication protocol.

Let's consider this analogy. Coca-cola makes purified water, uses it for coke production, and even sells it as a standalone product. But Coca-Cola is not considered a bottled water business. Coca-cola(OAuth 2.0 makers) use purified water (authentication) in the process of making coke (OAuth 2.0). But coke(OAuth 2.0 )is not purified water(authentication).

On the other hand, OIDC is an authentication protocol developed using some specifications of OAuth2.0, OpenID 1.0, and 2.0. It extends some features of OAuth2.0(specifically authentication and authorization) and can therefore meet both user authentication and authorization needs. As a result, it can verify user identities(authentication), access their resources (authorization), and fetch their profile information. It does all this via an ID token that contains proof that a user has been authenticated.

This image from Wikipedia perfectly captures the difference between OpenID Connect and OAuth2.0

OpenID Connect Message Flows and ID Tokens

We are aware that OpenID Connect enables simple user authentication online. Now, let's take a closer look at the process it employs to accomplish this. Authentication with the OpenID Connect protocol depends on two main actors, a message flow and an ID token.

The message flows are a series of steps (defined in the OIDC protocol) developers must use to communicate with OpenID-compliant IdPs. The most commonly used flow types are the server flow/authorization code flow and the "implicit flow."

The second actor, the ID token, is the end result of that communication. It's a small piece of data containing information that proves a user has been authenticated and is sent from the IdPs authorization server to the developer. Note that this back-and-forth communication happens via restful HTTP calls.

In part 2 of this article, I discuss in detail the different flow types, the ID token, and some others actors like the authorization server involved in the authentication operations of the Open ID connect protocol. I also provide a detailed example of using the most popular flow type.

Piecing it together(OpenID Connect, the identity provider, and your application backend)

I'm confident that you now understand the fundamentals of user authentication with OpenID Connect better. We are aware of OIDC and how it facilitates user authentication in an app, as well as what an identity provider service is and what it accomplishes.

But how do these three—OIDC, IdP, and app backend—integrate? How does your backend sign-up and sign-in logic incorporate the IdP and OIDC?

Luckily for us, identity providers like Google and Microsoft are OpenID certified and are part of the OpenID Foundation(the entity that developed OIDC). They have performed most of the heavy lifting for us regarding the usage of OIDC. They have OpenID-certified APIs and SDKs that developers can leverage for user authentication. Aside from these two, several other companies, like Yahoo, SalesForce, Okta, etc., are also OpenID certified and offer similar identity management services. Collectively they are called OpenID Connect Providers.

You can check out this link to explore all other IdPs that are OpenID certified if your app requires a provider other than Google.

I prefer to use Google's OAuth 2.0 APIs for my user authentication needs. These APIs are OpenID certified and can perform user authentication and client authorization where the client is a third-party app/site/device. This is the link to the Google OAuth API documentation, which I find relatively easy to use. It's direct and gives clear instructions.

So now, all you need to do is to create a developer account with any of these OpenID Connect Providers. Once you have the account, you can follow the steps in their API docs and integrate their OIDC APIs into your backend, and you are good to go.

Concluding Thoughts

Using OpenID Connect for sign-up/sign-in flows can be overwhelming when you don’t know where to begin. Hopefully, this article has given you a good head start. You can check out part 2 of my article here. It focuses on the most popular flow/processes for obtaining OIDC ID tokens. The OpenID Foundation and OpenID Connect are also sites you can visit for more in-depth information once you have a basic understanding of OIDC.