One Grant for All Cases?

In this blog, we will take a closer look at the Standard OAuth2 and in particular the Grant Types. OAuth2 is a standard protocol for authorization.

 

The decision to rely on the standards of OAuth2 in relation with OpenID Connect (OIDC) increases the security of clients and APIs, among other things. In addition, OAuth2 offers various options (Grant Types) for integration, which tend to lead rather to the opposite in case of misuse.

OpenID Connect is an authentication layer based on the OAuth2 Standard.

Flow vs. Grant

“Does that mean Flow or Grant or is it the same?” – OIDC describes 3 different Flows for authentication – the Authorization Code Flow, the Implicit Flow and the Hybrid Flow. Whereas the OAuth2-Protocol describes different Grant types. In this blog, we will take a closer look at what these are and what criteria are crucial for selecting the right Grant types.

Since the release of oauth2 in 2012, the number of grant types has changed repeatedly. At the beginning, there were among others the grant types Implicit Grant and the Resource Owner Password Credentials Grant, which have since been discontinued and have been completely removed in the current draft of the specification from oauth2.1. Therefore, we will not discuss either Grant type in detail.

The following are still available for selection:

• Client Credentials
• Authorization Code
• PKCE
• Device Code
• Refresh Token

This list can be shortened further if the current oauth2.1 specification is to be believed. It means namely that the Authorization Code Grant should be replaced by the PKCE Grant in all applications. So far, this has only been the case with client-side web applications and mobile apps.

The Refresh Token Grant is a special grant and cannot be used alone. Before you can use this grant, you must have collected an Access-Token and a Refresh Token via the Authorization Code Grant, the PKCE Grant or the Device Code Grant.

So, as things stand, oauth2.1 will significantly simplify our decision as to which Grant Type we should use. In order to decide on one of the 3 remaining Grant Types, we have to answer a maximum of 2 questions.

01. Does our application have user interaction?

E.g. No: Our application is, for example, a cronjob that creates reports every night and asks for weather data. The cronjob gets the Access-Token to query the weather data with the help of its Client-ID and Client-Secret via the Client Credentials Grant.

E.g. Yes: Continue to question 2

2. Does the target device have a browser and is it possible for the user to enter his credentials comfortably?

E.g. No: Our application runs on smart TVs and provides various movie content. Since the usability for entering the credentials is limited, the application fetches the Access-Token via the Device Code Grant.

E.g. Yes: Our application is a web store. Login and registration pages can be presented to the user in any form and for entering their credentials they have several options to choose from (keyboard, fingerprint, camera, etc.).

In the following table we have summarized the different app types and the recommended OAuth2 Grant Types again.

App-Type	Recommended Grant-Type	Optional Grant Type
Backend-Service, M2M communication	Client-Credentials
Regular WebApps (PHP, ASP.NET)	PKCE	Authorization Code
Single Page Applications, mobile Apps	PKCE
Apps for Smart-TV, Video-Console etc.	Device Code	PKCE, Authorization Code (both only if browser and some kind of input is possible)

Our short summary about OAuth2, especially the OAuth2 Grant Types and the classification of the Grant Types to the different use cases and application types, is intended to support the decision for the right OAuth2 grant. Therefore, enclosed a small decision diagram for an overview.