#OAUTH AND AUTOMIZE CODE#
#OAUTH AND AUTOMIZE PASSWORD#

The latter is the same for all OAuth2 grant types, while the former varies across grant types. ConclusionĮach OAuth2 grant type flow comprises 2 flows: get access token and use access token usage flow. Unless the App and the OAuth Server belong to the same entity, handing over the username/password to the App empowers the App with all the privileges as the User, which is a security risk.

#OAUTH AND AUTOMIZE PASSWORD#

Resource Owner Password Credential grant type flow is also easy having only 2 steps but it requires the User to hand over username/password to the App in Step #2. Resource Owner Password Credential Grant Type Flow Thus the use case for this grant type is limited, but secure as the key/access token is handed over to the App (backend), which is well-guarded.

Client Credential Grant Type FlowĬlient Credential grant type flow (leftmost) is easy, having only 2 steps but it requires the User to be the same entity as the App since the User will use the client id/client secret of the App to identity herself when communicating with the OAuth Server in Step #5. This flow is necessary when the App does not have a backend, such as a single-page app (SPA) or a native mobile app. This is often mitigated by provisioning key/access token that cannot be renewed and has shorter expiration.

#OAUTH AND AUTOMIZE CODE#

Implicit grant type flow (rightmost) is most similar to Authorization Code except Step #4 is not required, i.e., the OAuth server hands the key/access token directly back to the User/Browser This increases the attack surface of the system moderately since the key/access token in stored on the browser, which is more exposed to the internet than the App (backend). You can easily tell that Authorization Code (3rd from left) grant type flow is the most involved, i.e., it has all 5 steps, and it is also the most secure as the key/access token is only issued to the App (backend), which is well-guarded (Step #5), thus reducing the attack surface of the system.

‘N.A.’ means ‘not applicable’, i.e., the step is not required in the grant type flow.

The ‘safe’ icon represents the OAuth Server.

The ‘www’ icon represents the User/Browser.

App acquires Key/Access Token from OAuth Server by presenting secret Code and Client Secret.

OAuth Server solicits user permission to allow the App to perform something on her behalf.

OAuth Server authenticates user when she clicks on the App’s social login button, which is tagged with Client ID.

Pre-register Client (App) with OAuth Server to get Client ID/Client Secret.

In principle, the Get Access Token flow has 5 steps (as shown in the diagram below):

Use the authorization key/access token to perform something by calling a protected API endpoint on behalf of the user, e.g., post a tweetĭifferences Between OAuth2 Grant Type Flow DiagramsĮvery OAuth2 grant type flow differs only in the first part of the main flow:.

Acquire the authorization key/access token for the user from the OAuth provider, e.g., Twitter.

To obtain authorization key/access token, which represents a set of permissions, from the user, and perform something on her behalf.Similarity between all OAuth2 Grant Type Flow DiagramsĮvery OAuth2 grant type flow has the same goal: In the same vein here, we will compare the four OAuth2 grant types side-by-side, but from the perspective of data flow between the parties (user, web browser/native app, web service, OAuth provider) in each OAuth2 grant type. In our previous article, we introduced the four OAuth2 grant types by comparing them from the perspective of security, implementation difficulty, and use cases.

In this article, we want to create a simple introduction that enables engineers, managers, and investors to understand the high level flow of each OAuth2 grant type quickly at a glance through OAuth2 flow diagrams. There are 4 different OAuth2 flows, and to understand which best suit your needs, refer to this. OAuth2 is a standard for streamlining the process of enabling a user to grant authorization to a web service or application to access her data or perform something on her behalf on another web service (OAuth provider).

Oauth and automize