Security

Choose The Right OAuth2 Flow/Grant Types For Your App

NOTE: If you are new to OAuth2 Flow/Grant Types, take a quick look at OAuth2 Grant Types in Pictures to get and idea about what they are.

An OAuth2 grant type is a flow that enables a user to authorize your web service to gain access to her resource, e.g., the ability to tweet on Twitter,  in a secure manner.

A grant type flow involves 2 main parts:

  • Redirecting the user to the OAuth provider, e.g., Twitter, to get authentication & authorization, which results in an access token
  • Using that access token to gain restricted access to the user resource, e.g., tweet through her Twitter account

OAuth2 has 4 grant types/flows:

  • Client credential
  • Authorization code
  • Resource owner password credential
  • Implicit

This article will enumerate the conditions for choosing a grant type as well as rank them based:

  • Difficulty (1 to 3, with 3 being most difficult and complex)
  • Security (1 to 3, with 3 being most secure)

In summary, choosing the right grant type depends on:

  • Where the critical part of your application code is
  • Trust level between user and application

 

OAuth2 Terminology

Before we get started you have to be familiar with these common OAuth2 terminology

Entity Who Goal
Client (C) Your web service (WS), single-page app (SPA), or native app (NA). Access a resource on Resource Server (RS), e.g., Twitter, on behalf of a user, to provide a useful service to the user, e.g., tweet ‘goodnight’ daily to followers.
User-Agent (UA) Browser or native app Provide UI, e.g., social button, etc., for user to interact with C
Authorization Server (AS) Holds all user identities, e.g., Twitter Authenticates a user and ask her to grant C access to her resource and then issuing C an access token.
Resource Server (RS) Holds all user resource, e.g., Twitter has in possession all user accounts, follower lists, etc. Contains user resources and shares a particular resource with a C in possession of an appropriate access token
Resource Owner (RO) Owner of a user resource, e.g., a single Twitter account, which is the end-user Owns the user resource

 

OAuth2 Grant Types/Flows

Condition Grant Type/Flow Difficulty vs. Security Notes
If Client and Resource Owner is the same entity Client credential All the code is in the backend

Only the backend have access to the secret key and access token

If the main logic of application is in the backend, while front-end is only responsible for presentation Authorization code The critical parts of the code is in the backend

Only the backend have access to the secret key and access token

The application  your users are interacting with cannot launch a web browser, nor support redirection [1]

There is a high-level of trust between user and application, e.g., application is the operating system, which is open source, or high-level of trust between application and OAuth provider, e.g., the OAuth provider manufactures the application.

Resource owner password credential The user hands over his password credentials to the application, which is a security risk

The application can request a scope with complete access to user resource once it possesses password credential

Usually only for applications that run  in hardware/firmware or legacy applications

Application is a single-page application (SPA) or a native app, and interacts with user resource on OAuth provider Implicit The front-end code gains access to access token

Access token in front-end code has a probability of being compromised, e.g., when web browser has a security hole that exposes the access token to other websites the user is visiting

 

Now that you know which OAuth2 grant type/flow you need, create your social login button in under 90 seconds. We have lots of ready-made code snippets for Instagram, Github, Facebook, Twitter, Google, and more. If you cannot find what you are looking for, head over to OAuth.io and chat with our developers live.

 

[1]: https://www.scottbrady91.com/OAuth/Why-the-Resource-Owner-Password-Credentials-Grant-Type-is-not-Authentication-nor-Suitable-for-Modern-Applications