This is the 26th day of my participation in the November Gwen Challenge. Check out the event details: The last Gwen Challenge 2021

Authorization code

In authorization Code mode, a third-party application first applies for an authorization code and then uses the code to obtain a token (the most common mode is for the separation of the front end and the back end).

This approach is the most common process and the most secure, and is suitable for Web applications with a back end. Authorization codes are transmitted through the front end, tokens are stored in the back end, and all communication with the resource server is done in the back end. This separation of the front and back ends prevents token leakage.

The implementation process

  1. Website A provides A link, and users will jump to website B after clicking it, and authorize user data to website A for use.

    https://b.com/oauth/authorize?
  response_type=code& 
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read
Copy the code
    • response_type=code The code parameter indicates that an authorization code is required
    • client_id=CLIENT_ID The parameter lets B know who is requesting data
    • redirect_uri = CALLBACK_URL The redirect address of site B after the link request has been processed
    • scope=read Indicates the scope to be authorized. Read indicates that the authorized resource is read-only

  2. If the jump succeeds, site B will ask the user to log in and then ask if they agree to authorize site A. The user agrees, and site B jumps backredirect_uriParameter specifies the url. When a jump occurs, an authorization code is returned

    https://a.com/callback?code=AUTHORIZATION_CODE // code indicates the authorization code
Copy the code

  3. After site A gets the authorization code, it can request A token from Site B at the back end.

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

Client_id Specifies the identity of A

Client_secret Verifies the identity of USER A

Grant_type: obtains the authorization code in authorization mode

Code Indicates the code value obtained in step 2

Redirect_uri Callback address after the token is issued

  1. B once the site receives the request, it issues a token. The specific approach is toredirect_uriSends a piece of JSON data to the specified url.
{    
  "access_token":"ACCESS_TOKEN"."token_type":"bearer"."expires_in":2592000."refresh_token":"REFRESH_TOKEN"."scope":"read"."uid":100101."info": {... }}Copy the code

hidden

WEB applications that are pure front-end applications must store tokens in the front-end. Allows to issue tokens directly to the front end. This approach has no intermediate step called an authorization code, so it is called “implicit.” Because the front-end directly obtains the token, the security is low, generally applicable to more trusted websites, and the validity period of the token is relatively short, generally the interface is closed and invalid

The implementation process

  1. Website A provides A link that requires users to jump to website B and authorizes user data to be used by website A

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

    Response_type =token returns the token directly

  2. The user goes to website B and agrees to authorize website A after login. B website will jump backredirect_uriParameter specifies the redirect URL, and the token as the URL parameter, passed to website A.

    https://a.com/callback#token=ACCESS_TOKEN
Copy the code

    The token parameter is a fragment of a URL, instead of a querystring. This is because OAuth 2.0 allows a URL to be redirected to HTTP. Therefore, there is a risk of “manin the middle attack”. The anchor points are not sent to the server, reducing the risk of token leakage.