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:
- Whether any part of your code is private, thus can store a secret key
- 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 (green) vs. Security (blue) | Notes |
| If Client and Resource Owner is the same entity | Client credential |  |
All the code is in the backend
Backend code is private so it can hold the secret key, which is used for acquiring access token |
| If the main logic of application is in the backend, while front-end is only responsible for presentation | Authorization code |  |
The backend code is private so it can hold the secret key, which is used for acquiring 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.
Why would you use an implicit flow for native apps? You can implement an authorization code flow by using a native browser to manage the redirects for the login!
Hey Matthias,
Good point! Authorization Code Flow is more secure, but it requires the user-agent to support redirection. Native apps by nature does not support redirection but you are right that using a ‘native browser’ is a great alternative! Thank you for your great input!