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

Cryptic phone

RFC 6749 also allows users to give a user name and password directly to an application if you have high trust in it. The app uses your password to request a token, which is called “password”.

The implementation process
  1. In the first step, site A requires users to provide the username and password of Site B. After receiving it, A directly requests the token from B.

    https://oauth.b.com/token?
      grant_type=password&
      username=USERNAME&
      password=PASSWORD&
      client_id=CLIENT_ID
    Copy the code
    • grant_type = password The authorization mode is password
    • username && userpassword B Login user name and password of the website
    • client_id The identity of the token requested by the user
  2. B after the website authenticates the identity, it directly gives the token. Notice that instead of jumping, you put the token inside the JSON data as an HTTP response, and A gets the token.

    This method requires users to provide their own user name and password, which is obviously risky. Therefore, this method is only applicable to situations where other authorization methods cannot be adopted, and users must have high trust in this method


Proof type

Credential is similar to cipher, and is mainly suitable for command line applications without a front end. You can obtain the token in the simplest way and return the token in the JSON result of the request response.

The implementation process
  1. In the first step, application A makes A request to application B at the command line.
https://oauth.b.com/token?
  grant_type=client_credentials&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET
Copy the code

Grant_type set to client_credentials indicates credential authorization, and client_id and client_secret are used to identify identities.

  1. B After the website is verified, the token is returned directly.

Token usage/update

use

After site A gets the token, it can request data from Site B’s API. You do this by placing the token in an Authorization field in the HTTP request header.

update

Once the token expires, it needs to be acquired again. When the token expires, if the user is asked to go through the above process again and apply for a new token, it may not be a good experience and it is not necessary. OAuth 2.0 allows users to update tokens automatically

Implementation method

Specifically, when website B issues tokens, it issues two tokens at a time, one for obtaining data and the other for obtaining a new token (refresh Token field). Before the token expires, the user uses refresh Token to issue a request to update the token.

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

When grant_type is set to refresh_token, the token is required to be updated.

The client_id and client_secret parameters are used to confirm identity;

The refresh_token parameter is the token used to update the token.

B once the site is authenticated, a new token is issued