If you’ve ever gone to sign-up for a new account and been prompted to log in through one of your existing accounts (say signing up for Instagram by using your Facebook credentials) then you’ve used OpenID Connect, or OIDC for short.

Open ID Connect verifies the identity of the resource owner, improves security, and simplifies the sign-up process for users. For anyone building platforms or apps, OIDC offers a user experience that has the potential to drive an uptick in sign-ups and conversions.

The first place to start is to understand the difference between authentication and authorization.

Building on OAuth 2.0, which acts as the authorization protocol, OpenID Connect (OIDC) is an identity authenticator.

It’s a common method of single sign-on (SSO), which verifies the identity of a user across multiple platforms, allowing the resource owner to access a whole host of apps with only one set of sign-on credentials.

To fully wrap your head around OIDC, it’s important to brush up on some key concepts and definitions, including:

• Scope - refers to what information is needed to verify the ID or the resource owner. This usually looks like a name, username, or email address.
• IdP or Authorization Server - ****the IdP authenticates the resource owner and handles authorization, granting the client the Access Token.
• Resource owner - or the ‘end user.’ This is the person (or entity) that owns the identity and sign-in data.
• Resource server - the entity that is holding the resource, typically the original application or server where the data was created or stored. For example, if you’re using your Google credentials to access Facebook, Google is the resource server in this scenario.
• Client - the application that is requesting the data. In the above scenario, Facebook is the client.
• Access Token - the client uses an access token to access data from the resource server. There’s no mechanism to determine who is the correct owner. Think of this like physical cash: whoever holds it can use it.
• ID Token - this is the security measure, verifying the correct owner of the data, sort of like a passport, in the form of a JSON Web Token (JWT.)

OIDC uses the authorization and authentication processes set out in the OAuth 2.0 framework. OIDC creates a ‘federated identity,’ signing a user on to one domain using the digital ID, or sign-on credentials, of another application.

Creating a federated identity gives the user more control over their digital ID and offers stacks of benefits such as reducing security risks and streamlining the sign-up process.

But how?

Building on the specifications of OAuth 2.0, OIDC utilizes JSON Web Token or JWT (more on that later) and can be used across any IdP that also utilizes this protocol.

OIDC follows the same flow as OAuth, but factors in an initial request specifying scope, and finally, the client receives both an access token and an ID token.

The access token allows the resource server to determine if the token is valid, the ID token or JWT allows the client to access information like the resource owner’s ID, and login, as well as hold data regarding security concerns including attempts to corrupt or steal the data.

OIDC is reliant on the underlying OAuth 2.0 protocol and operates similarly. However, OIDC also includes a specific scope of OpenID. OAuth 2.0 works to share resources and grant access, whereas OIDC works to make SSO possible across multiple apps and verify the identity and access limitations of the resource owner.

One way to think about the difference here is: OAuth 2.0 is a key that allows access and relays authorization between apps. OIDC sits on top of this and carries profile information containing details of the resource owner’s identity, allowing the user to create a sign-on session or process authentication.

OIDC also extends on OAuth by also including a specific scope and JSON Web Token (JWT).

A JWT is a specific type of access token regularly used by OIDC. It acts as an ID card or passport and verifies the resource owner’s identity.

Here’s where things get more technical. JWT is an open standard RFC 7519. It’s a succinct way of transmitting information safely and securely. It transmits as a JSON object, and because the information comes digitally signed, it’s easy to verify and highly trustworthy.

Once the resource server has authenticated with the client, authorization is granted by the OIDC to access the digital ID, the server then sends the information about the resource owner to the client. This information is sent as a JWT.

And if you’re wondering, the code looks something like this: “xxxxx.yyyyy.zzzzz.”

It’s easy to see how convenience here is a big seller, as OIDC streamlines the sign-in process for the resource owner. Rather than filling out registration forms and personal information to create new accounts, these details are taken from an existing and trusted account with just a few clicks.

Not only is it more convenient, but it also allows for more control over online identities. As a protocol, OIDC is decentralized, meaning it doesn’t require a service provider, webpage, or governing entity. The resource owner determines how much personal information is shared, and with who.

The reach it offers is a big drawcard for users, too. An app or platform can be accessed from any device through OIDC, whilst reducing the risk of exposing passwords and sensitive information to hackers.

Often, when security threats happen, the responsibility sits with organizations and enterprises. But with OIDC, these parties are better protected. OIDC is multi-layered and offers scope for scalability. Regardless of the number of sign-ins, OIDC keeps security and online safety at the forefront.

At the forefront of modern sign-on tech, OIDC is a secure way to streamline the sign-in experience. The prevalence of data leaks and cyberattacks is only rising, meaning it has never been more important to ensure users’ digital data is stored securely.

See how Kinde compares to other authentication providers.