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
-
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
-
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
- 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.
- 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