Introduction Of OAuth2.0 and OpenID

OAuth is an authorization protocol that allows a user to access a resource in another application without sharing the login credentials.

Eg, “Login with Facebook”

We have seen this option in most customer-facing web and mobile applications. When we use this to authenticate, the website doesn’t try to get the login credentials of Facebook. Instead, Facbook is going to verify the user and provide the token.

Basic OAuth2.0 Authorization flow diagram

OAuth2.0 Terminology

Resource Owner

The person who owns the data that the application is going to fetch. The person who can allow the application to use the data. For example, the application might call an external system's API to get the email address of the user from their profile. The end user can approve or deny the request to access the data.

Client

The application that is requesting access to the resource owner. The client could be a single-page web app or a web API that calls another web API. Usually, the client will be referred to as Client application or simple application.

Authorization Server

The one that verifies the user. Sometimes it is referred to as Identity Provider or IDP. In the previous example, it will be Facebook. It handles the data, the access, and the relationship between the parties. The authorization server issues the tokens, which are much needed for the application to grant, deny, or revoke access. 

Resource Server

Hosts or protects the data or APIs that are being accessed. A web API in front of the data source.

Back channel

It is a more secure way of connection. In the authorization flow, the access token will be transferred via a back channel.

Front channel

Is it secure, but some loopholes make it not very secure when compared with a back channel. An example will be the browser. When a password is entered in a browser, anyone can view the password if they open the network console. The authorization code is transferred via the front channel.

OAuth2.0 and OpenID Connect

Both are protocols for authorization and authentication. OAuth 2.0 is primarily for authorization, and OpenID Connect is for authentication that is built on OAuth2.0.

OAuth provides authorization to access native and web applications. OpenID Connect extends OAuth with authentication. It helps in retrieving and storing the authorization details to access the data. The below

OpenID Connect adds an ID token, UserInfo to retrieve more about the user information and more standardized implementation compared to OAuth in addition to OAuth.

Tokens

In authorization flow, bearer tokens are always used for verification and authentication. Three types of bearer tokens have been explained below.

Access Token

Issued by the authorization server. The client's granted permission will be in the access token. The client passed the access token to the resource server. Access tokens have a short lifespan.

ID Token

It contains the identity information. When signing in, the client uses the ID tokens to get basic information about themselves.

Refresh Token

It is used to get new access and ID tokens if they have expired. The refresh token should be treated as sensitive data.

Conclusion

For a single-page web application, a native/ mobile application, and a regular application, OpenID Connect is used for authentication and for delegated authorization - OAuth 2.0 is used. OpenID Connect is all about logging the user in and making your accounts available in other systems. OAuth0 is about granting access to user data in other systems.