OAuth 2 — What OAuth flow to use and how
Since reading the OAuth 2 spec can be difficult, I’ve created this article to explain the terms in a straightforward manner. The core specifications could be complex with a lot of information and leaves the developer with many decisions based on security tradeoffs etc. Rather than detailing all of the decisions that must be made in order to effectively implement OAuth 2, this article focuses on the ones that are most relevant to most developers looking to implement OAuth 2. And also gives a clear idea which OAuth 2 flow should be used based on the circumstances. This article will include a real world example with OAuth.
Before we understand the concept behind this. Let’s look at the roles in OAuth 2.0.
- Resource Owner: A person or entity who has the authority to allow access to a protected resource. This is usually the end-user.
- Client: An application that, on behalf of the Resource Owner, requests access to a protected resource.
- Resource Server: This is the server that contains the protected resources. This is the API you want to access..
- Authorization Server: A server that verifies the Resource Owner’s identity and issues Access Tokens after proper authorization has been granted.
Creating an App
You must first register a new app with the service before you can begin the OAuth process. When you register a new app, you normally fill out basic information like the app’s name, website, logo, and so on. You must also register a redirect URI that will be used to redirect users to a web server, browser-based, or mobile app.
Redirect URIs
The service will only send users to a URI that has been registered, which helps to prevent certain attacks. Any URIs that redirect to HTTP must be delivered over HTTPS. This minimizes the risk of tokens being intercepted during the authorization process.
Client ID and Secret
You will obtain a client ID and, if requested, a client secret after registering your app. The client ID is considered public information, and it is used to create login URLs or include in JavaScript source code on a page. It is essential to keep the client’s secret private.
What are the different types of flows and which OAuth 2 flow should you use. For various use cases, OAuth 2 provides various “grant types.”
- Authorization Code
- Password
- Client credentials
- Implicit
Is the Client absolutely trusted with user credentials?
If the Client is an usual web application running on a server, the Authorization Code Flow must be used. The Client can use this to get an Access Token and, if necessary, a Refresh Token. It’s the safest option because the Access Token is sent directly to the web server hosting the Client, avoiding the user’s web browser and reducing the chance of vulnerability.
Is the Client a mobile app of the same resource application and absolutely trusted with user credentials?
The Resource Owner Password Credentials Grant could be used in this circumstance. The end-user is prompted to provide credentials (username/password) in this flow, which is usually done through an interactive form. These credentials are sent to the backend, which then passes it along to Authorization Server. As a result, the Client must be completely trusted with this data. Token has high privilege and long expiry
Is the Client a Single-Page App?
There are two grant possibilities if the Client is a Single-Page App (SPA), which is an application that runs in a browser and uses a scripting language like JavaScript. The Authorization Code Flow with Proof Key for Code Exchange (PKCE) and the Implicit Flow with Form Post are both possible. Because the Access Token is not visible on the client side and this flow can return Refresh Tokens, However the recommended way is using the Authorization Code Flow with PKCE in most of scenarios.
Does the Application only share general resources and not user resources?
In this circumstance the general resources then Client credentials is the best option. The resource data can be throttled based on the scope and can make the users access only some functions through the API in a secure way. An example of this grant type would be google maps
Now Let’s look at a real world example using OAuth to get a practical understanding about the concept. The following project source code could be found in GitHub.
Sample project scenario
The ‘CloudUp’ is an online web application to upload files and manage user contents(Text files, Images, pdf files etc.) in dropbox with ease. This application is developed using ReactJS for the client side (frontend) , NodeJS on the server side (backend runtime environment ) and ExpressJS (backend web framework). Additional Bootstrap v4.4 is used for styling purposes.
This web application uses OAuth 2.0 framework to authorize the application with Dropbox Authorization server and retrieve access token using Authorization code grant type. Application allows the user to create folders in dropbox based on their preference and upload files into it with very few clicks. Use case of this application is to enable users to manage assignments materials, Images, Tutorials, Entertainments contents by allowing to create structured folders in a well organized manner and also enable users to upload relevant files in organized structured folders. The use of OAuth 2.0 further makes it simpler for the user as there is no additional registration process involved. The overall message flow diagram is illustrated below.
Message flow
Authorizing CloudUp — Content Manager Application
Initially the user is directed to the ‘Cloud up’ login page and has to connect to the Dropbox server by clicking the Sign to Dropbox button in the login page (Figure 3.1) which will send a http GET request to the Authorization endpoint to obtain authorization code which will redirect the user back to Dropbox login to authenticate and give consent to the CloudUp or the Content Manager Application to access Dropbox Resource server with specified privileges (scopes).
Once the user allows the authorization code is generated and CloudUp initiates a POST request to the Token endpoint with the authorization code to obtain the token. Token with specified privileges to create folders and upload files is retrieved as shown below.
Access Token Info :
Accessing Dropbox Resource API
Finally the token is used to to create folders and as per user preference and upload files using the following API’s
Create folder API : https://api.dropboxapi.com/2/files/create_folder_v2
Upload file API : https://content.dropboxapi.com/2/files/upload
Github Link https://github.com/TheTechTitan/ssd-oauth-project
Conclusion
Summarizing everything — The OAuth 2.0 authentication protocol is a simple HTTP-based solution that may be used on essentially any platform. This article explains the concept OAuth in a very simple manner and gives a clear idea on how it fits different use cases. Furthermore, the article include a real world example project implemented with OAuth.