What is OAuth 2.0 and OpenID Connect?

OAuth 2.0 is a framework designed to authorize applications and enable those applications to get limited access to a given resource. For example, if an application needs to access your email contacts, it requires that your email provider authorizes that access.

Note that OAuth 2.0 was not designed for authentication, it was designed for authorization. OAuth 2.0 is essentially made for granting permissions and get access within a certain scope. It does not care about who the user is as long as it has the correct access policy.

That is where OpenID Connect comes in and fills that gap. OpenID Connect is a simple identity layer that sits on top of OAuth 2.0 and is essentially an extension. Thanks to OpenID we can effectively add user information through an ID token which is composed of a Token + some user information. Now with that setup, both authorization and authentication can be done. Together, OAuth 2.0 and OpenID connect are becoming one of the industry’s best and common practices for handling security.

Before we dive further into how the process works, is good to get familiar with some of the terms used by OAuth 2.0

• Resource owner: The entity that is able to grant access to a protected resource. This just means the user, the owner of the data being access, the person who is going allow access.
• Client: The application that wants to access the data.
• Resource server: The system that actually holds the protected resources (Data). Often the same as the authorization server. Sometimes they are separate entities, or sometimes is one system.
• Redirect URL: Refers to the callback, where should the user end up once they confirm access, this usually is the client app. Essentially, where is the access code being sent to.
• Access token: The key the client can use to access the data they requested.
• Authorization server: The System that manages the permissions, the entity that issues the access token to the client.
• Authorization grant: The thing that proves that the user allowed access to a given resource.

How does OAuth 2.0 work?

Basic Authentication Flow

1. The client sends the request to access a protected resource. In this request, you specify the scope and the type of response. Note that the scope and request type are space-delimited fields and you can specify more than one scope and type combination. The response type tells the server which type of grant to execute.
2. The user is prompted to approve the permission and/or input the credentials
3. The authorization server sends back an authorization code to the client
4. The client can now use that authorization code to exchange it for an access token
5. The client can now use the access token to access the protected resource

Note that the flow may have some variations depending on the type of application and whether the application has a backend system.

Using OAuth 2.0 with OpenID Connect

Here’s a quick example of how an OpenID configuration would vary from the above:

Implicit flow

For OpenID Connect, you need to specify the scope as openid and you could use the id_token request type (Implicit flow). This request type indicates to the server that the application would like an ID token alongside or instead of the access token in the response from the /authorize endpoint and can be used by the client to authenticate the user.

1. The user is prompted to approve the permission and/or input the credentials
2. The authorization server sends back the tokens given that the implicit flow is being triggered by passing the id_token response type.
3. The client can now use the access token to access the data.

Summary

Use OAuth 2.0 when:

• Need authorized access to APIs
• Need authorized access to protected resources in other systems

Use OpenID connect when:

• Need to authenticate a user