4 ways to obtain access token in OAuth 2.0

OAuth 2.0 is an authorization mechanism, it's ,mainly used for issuing access token. There are 4 ways to obtain access token as per RFC 6749.

• Authorization code
• Implicit
• Password
• Client credentials

The third party application must obtain a client id and client secret from the target service before obtaining access token no matter which method to use. This is to prevent token to be used maliciously.

Authorization code

With this method, the third party application must first get an authorization code and then use this authorization code to exchange the access token. This is the most commonly used method and it is also the most secure method. It is applicable to those web application with backend. The authorization code will be sent back through front end but the process of exchanging the access token is done through backend call between request and resource servers. This can prevent access token leakage.

The first step of this method is that website A provides a link, it will redirect to website B when user clicks it to provide authorization of data access to website A. Below is a sample link to link to website B.

https://b.com/oauth/authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

response_type mends website A wants to get the authorization code, client_id indicates who is requesting the resource, redirect_uri tells website B that where to redirect after the request id completed, scope indicates what kind of resource to return.

The second step comes to website B, it will ask the user to login if the user hasn't login yet. Then it will ask the user whether to authorize website A to access his/her resource on website B. If user authorizes it, website B will redirect to website A with an authorization code.

https://a.com/callback?code=AUTHORIZATION_CODE

In third step, website A will send a request to website B from backend server using the autorization code obtained above.

https://b.com/oauth/token?
 client_id=CLIENT_ID&
 client_secret=CLIENT_SECRET&
 grant_type=authorization_code&
 code=AUTHORIZATION_CODE&
 redirect_uri=CALLBACK_URL

client_id and client_secret are for website B to get to know identify of website A(client_secret can only be sent through backend, grant_type will be authorization_code to indicate the authorization method is authorization code, code is the authorization code obtained above, redirect_uri is the redirect URL after issuing access token.

The fourth step is for website B to return the JSON data containing the access token to website A.

{    
  "access_token":"ACCESS_TOKEN",
  "token_type":"bearer",
  "expires_in":2592000,
  "refresh_token":"REFRESH_TOKEN",
  "scope":"read",
  "uid":100101,
  "info":{...}
}

Implicit

Some web applications don't have backend at all(some single page application), in this case, above method is not feasible. The access token must be sent through front end. RFC 6749 introduces the second method which is to issue access token to front end directly. There is no intermediate step in this process.

The first step is similar to above method.

https://b.com/oauth/authorize?
  response_type=token&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

The major difference here is that the response_type is token instead of code as it requests website B to return access token directly.

The second step requires website B redirects back to website A with the access token as a URL parameter.

https://a.com/callback#token=ACCESS_TOKEN

Note that the token is not passed back as query string but as a hash token. This is to reduce the risk of leaking the token as access token will normally not be passed to backend server.

This method is the most insecure method and the lifespan of the token should only last through the session life time.

Password

If an app is highly trusted by others, RFC 6749 also allows users pass the username and password and let the app use your username and password to obtain the access token on behalf of you.

The first step is website A asks user to enter username and password of website B. Thereafter A will sends request to B.

https://oauth.b.com/token?
  grant_type=password&
  username=USERNAME&
  password=PASSWORD&
  client_id=CLIENT_ID

grant_type is the grant type where password means it's password type. username and password are the username and password of user respectively.

In second step, website B will issue the access token directly after verifying username and password. There is no redirection in this flow as the access token will be in the response.

This method has high risk as user needs to surrender their username and password of website B to website A.

Client credentials

Client credentials is applicable to cases where there is no front end.

The first step is app A will send request to B.

https://oauth.b.com/token?
  grant_type=client_credentials&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET

grant_type is client_credentials in this case, client_id and client_secret are used for B to verify identify of A.

After verification, B will issue the access token to app A directly. The access token issued in this case is for the third party application, not specific to a user which means multiple users would share the same access token.

After website A obtains the access token, it can use it to request resource by putting it in the Authorization header of every API HTTP request.

curl -H "Authorization: Bearer ACCESS_TOKEN" \
"https://api.b.com"

When sometimes an access token needs to be refreshed, OAuth 2.0 allows user to refresh the token to avoid going through the above process again. Website B will issue two token at once: refresh token and access token. Before access token is expired, user can use refresh token to obtain a new access token.

https://b.com/oauth/token?
  grant_type=refresh_token&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET&
  refresh_token=REFRESH_TOKEN

Once verification is done, a new access token will be issued to the user.

Reference: http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html