OAuth2.0 vs OpenID Connect (OIDC) - What? Why? How?

Introduction

This article demonstrates core concepts of OAuth2.0 and OpenID Connect. At the end of this article,
you will have a clear understanding on the below points:

1. What is OAuth2.0?
2. Actors in OAuth2.0 framework
3. Brief OAuth2.0 workflow diagram
4. What are Issues not handled by OAuth2.0?
5. Why do we need OpenID connect?
6. What is OpenID connect?
7. When OpenID Connect can be useful?
8. Brief workflow diagram using OIDC
9. Example of OpenID Connect and OAuth2.0
10. A modern applications architecture using OAuth2.0 and OIDC
11. Implementation Approach

What is OAuth2.0?

OAuth stands for Open Authorization.

It's used for delegated authorization to delegate the responsibilities of user authorization to some
other service rather than managing them on its own.

It enables a client’s app to use resource servers on behalf of resource owners on exchange of
access token.These resources could be photos, contacts that are usually stored with other
providers. OAuth does this by granting the requesting client application a token, after user approves
access. Each token grants limited access to specified resources for a specific period.

OAuth is not a password sharing mechanism or protocol. It is“How can I let third party website
access my data without giving my password”. The misunderstanding comes down to Authentication
versus Authorization. Authentication is who you are while authorization is what you can do.
Authorization depends on authentication but they are not interchangeable.

If we resemble the same with real life example like “check-in into a hotel”. When you check in to a
hotel, you present to the reception with your driving license or passport. This establishes who you
are i.e. your identity. Then hotel receptionist issue you a key card that encoded with what you have
access to, which will include your room access, it might also include the gym or swimming pool
access too. That is your authorization. The best part is that your personal and billing information
never leaves the front desk. This is OAuth.

In terms of OAuth terminology, you are the client. The front desk is the authorization server, which
evaluates the authorization policies. The key card is an access token, representing the result of
those policies. In addition, your room, the gym, etc., are the resources you want to protect.
Fundamentally, OAuth is an authorization framework.

Actors in OAuth2.0 framework

  User/Resource Owner
Owner of a user resource i.e. end-user who is giving access to some portion of his/her
account.
 User-Agent
Browser or native app.
 Client Application
The application that is attempting to get access to the user’s account or a resource on
Resource Server i.e. APIs. This application could be website, desktop or mobile app.
 Authorization Server
The server where the client applications are registered. It holds user identities,
authenticates a user, and ask him/her to grant client app to access protected resource
hosted by a resource server and then issuing an access token to client app.
 Resource Server
The Web API or web service that hosts the secured and protected user resources and
protected by OAuth. It shares user resources with client app in possession of an
appropriate access token.

Brief OAuth2.0 workflow diagram

1. The resource owner sends a request to the OAuth enabled client application
2. The OAuth client submits an authorization request to the server, which validates that the
client is a legitimate client of its service. OAuth authorization server authenticates the user
and presents consent page. It then sends the authorization code to the OAuth client.
3. The OAuth client uses the authorization code to retrieve an OAuth token from the OAuth
server.
4. The OAuth client presents the access token to the OAuth resource server.
5. The resource server validates token with authorization server.
6. The resource server provides the requested content to the OAuth client.

What are Issues not handled by OAuth2.0?

OAuth2.0 leaves many details up to implementation.

 It supports scope, but scope names are not specified.

 It supports access token but access token formats are not specified.
 Since the only thing it handles is authorization, the framework does not support end-user
authentication by itself.

Why do we need OpenID connect?

There are many situations where the application needs to know who logged in and the API certainly
needs to know who the user is.

However, OAuthdoes not say anything about how to do that.That is why we need something beyond
OAuth which is OpenID connect.

Other thing to keep in mind about OAuth is that it was originally created and designed for third-party
apps, like it the Spotify app is trying to access your contacts from Google. However,things have
matured over time; the OAuth framework actually provides a very good solution for first party apps
as well.
What is OpenID connect (OIDC)?

It is an identity layer on top of OAuth2.0. The two fundamental security concerns, authentication and
API access, are combined into a single protocol called OpenID Connect.

OpenID connect will give you an access token plus an id token. The id token is a JWT and contains
information about the authenticated user. The identity provider signs it.

In addition, OpenID connect standardizes quite a couple things that oauth2 leaves up to choice for
instance scopes, endpoint discovery, and dynamic registration of clients.

It has become the leading standard for single sign-on and identity provision on the internet.

Simple JSON based identity token (JWT) delivered via OAuth2.0 flows designed for web, browser
based and native application.

With ODIC, a number of specific scope names are defined that each produce different results.
Scopes are space separated lists of identifiers used to specify what access privileges are being
requested. Built in scopes are,

1. openid: This is mandatory scope

2. profile: request access to default profile claims like name, picture , birthdate etc.
3. email: requests access to email and email_verified claims
4. address: request access to address claim
5. phone: requests access to phone_number and phone_number_verified claims

Claims are name/value pairs that contain information about a user as well as meta-information about
OIDC service.

It provides structure to a user profile, and allows you to selectively share it. To continue with our
analogy from earlier, let us say you want to eat at the hotel restaurant. With OIDC, you can share
your food allergies, and those alone, but not your e-mail address. Allowing you to share specific
things is just authorization all over again. In addition, that is right; OpenID Connect is just a special
case of OAuth. It is designed specifically for single sign on use cases, and sharing profile
information.

When can OpenID Connect can useful?

There are three situations where using OIDC can useful.

Instead of asking users to create yet another account in client website, we could take advantage of
OIDC to integrate with an identity provider to reuse their existing accounts on an identity providers
like Google or Facebook etc.

OpenID Connect can be useful is when the protocol is used to create a hub of identity providers. In
this scenario, instead of making your application communicate with multiple providers, you can make
it connect to a single identity provider that acts as a hub for the others.

OpenID Connect can be works as a proxy for other protocols like SAML.
Brief workflow diagram using OIDC

The below workflow depicts how OpenID works internally and serves user requests step by step,
including authentication delegation to protected resource access using access token.

Example of OpenID Connect and OAuth2.0

One of the simplest examples ever to understand the difference between OpenID Connect and
OAuth2.0:

OpenID Connect: Sign in with Google, Facebook, LinkedIn (i.e. third party identity provider) or your
own identity server in your application (i.e. Azure AD or IdentityServer4 etc.).

OAuth2.0: This could be the consent that you/resource owner are granting to the client app and
authorizing the app to access protected resources.

A modern application's architecture using OAuth2.0 and OIDC

Below is the architecture of a modern application where client application could be Browser-based
app, Native app and Server-based app that can communicate with Web App and WebAPIs. OIDC
and OAuth 2.0 combination is the best approach to secure those applications nowadays using a
security token service.

Implementation Approach

1. If you want to allow your app to use third party OpenID provider like Google or Facebook
etc., then easily integrate them with your application using documentation provided by the
respective providers.
2. You can build your Identity provider. For example - IdentityServer4 which is an OpenID
Connect and OAuth 2.0 framework for ASP.NET Core.

Conclusion

In this article, we have gone through some of the core concepts of OAuth2.0 and OpenID Connects
– What is it? Why do we need it? How does work? When trying to understand OAuth, it can be
helpful to remember that OAuth scenarios usually represent two unrelated sites or services trying to
accomplish something on behalf of users or their software. Whereas OpenID Connects (ODIC)
enables different types of applications to support authentication and identity management in a
secure, centralized, and standardized way.