OAuth2.0 vs OpenId Connect

I have written this article almost 5 years ago (previously in French) for one of my previous companies. I was working on an IAM product for various customers and this question was always there, what are the differences between OAuth and OpenId Connect (OIDC).

This article is here to decrypt a bit more these 2 protocols, I will not dig too much inside the protocols but this will give you more inputs on OAuth2.0 and OIDC and help you to understand when to use them.

What is OAuth2?

Most of the time when we think OAuth2 we are seeing that as a protocol that allows access to a service via a federated identity, managed by someone else. And this exactly what OAuth2.0 is not.

OAuth2.0 is an authorization protocol, it allows a consumer (a website, an app or any software) to access to a private API with authentication.

To make it clear, OAuth2.0 is not designed to federate the authentication to a third party but delegate the authorization of API.
But we can still use it to authenticate users, for this we need two steps:

  1. The user gets an authorization token called accessToken directly from the third-party website (for example Facebook).
  2. After the authentication to the third party, we can call an API (with the accessToken) served by the third party to get information about the user associate to the accessToken.

After that, on the consumer, we now know who is the user and we can identify him.

OAuth2 authentication server flow

What is OpenID Connect?

OpenID Connect is the third version of the OpenID protocol, this is an authentication layer over OAuth2.0. This protocol checks the identity of a user with an identity provider.

All the operations are made through REST API and all the data are in JSON. OpenID Connect brings some new features after OpenID 2.0:

  • The possibility to sign and cipher the data.
  • Standardization of the data in the ID token which is a JWT token to identify the user. All the fields of the ID token are named the same for each IDP and it also defined which fields are mandatory.
    Standardization does not exist in OAuth2.0, so you have to implement some logic for every federation.

Example of an ID Token:

"iss": "http://server.example.com",
"sub": "248289761001",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"gender": "female",
"birthdate": "0000-10-31",
"email": "janedoe@example.com",
"picture": "http://example.com/janedoe/me.jpg"

At the end of the flow bellow, you can see that we don’t have to call an extra API to know who is the user, we get all the information in the ID Token.

OpenID Connect Server Flow

When using OAuth2.0 and OIDC?

I am sure you using OIDC and OAuth2 every day without notice it.

Every time you connect to you spotify using facebook or medium with google you are using one of these protocols.

So if you want to use an identity from a third-party or if you want to let another service to use your identity, OIDC is for you. OIDC is more secure with the JWT ID Token and the possibility to have a ciphered and a signed token. It keeps the integrity of your identity.

The normalization is also great because you’re integration with other identity provider is always the same.

OAuth2.0 you should use it if you want to protect your API with an authorization token. This is used by most of the popular API like Gmail, Facebook graph API … Just avoid exposing an API who gives information about the user.

Why OpenID Connect and OAuth2.0 are different?

To conclude we can say that great thing about OpenID Connect is that it standardizes the flow for person authentication using OAuth2. Previously we had too many proprietary API’s that did the same thing.

Along the way, OpenID Connect also defines standards for Discovery (Webfinger), Dynamic Client Registration (so you don’t have to ask every website for a client id and password manually…), and session management (logout).

OAuth2.0 is still great and used by a lot of companies, but if you start from scratch I will recommend implementing OIDC because this is more future proof!

Techlead and cloud architect, I like to build great apps and deploy them on the cloud ☁️ ☁️ ☁️ #aws #go #java ☕️ #typescript #cicd