Introduction to Oauth2.0 authorization

This article reprinted from: www.ruanyifeng.com/blog/2019/0…

OAuth 2.0 is an authorization mechanism, mainly used to issue tokens. This article goes on to describe the practice of issuing tokens.

RFC 6749

The standard for OAuth 2.0 is RFC 6749 files. The file begins by explaining what OAuth is.

OAuth introduces an authorization layer to separate two different roles: client and resource owner. . With the resource owner’s consent, the resource server can issue the token to the client. The client requests data through a token.

The core of OAuth is to issue tokens to third-party applications. RFC 6749 then goes on to say that (since there are multiple scenarios on the Internet) this standard defines four authorization grants for obtaining tokens. That is, OAuth 2.0 specifies four processes for obtaining tokens. You can choose the one that works best for you and issue tokens to third-party applications. Here are the four ways to authorize.

• Authorization-code
• Implicit
• Password:
• Client credentials

Note that in either authorization mode, third-party applications must register with the system before applying for a token, state their identity, and receive two identifiers: client ID and Client secret. This is to prevent misuse of tokens, and third-party applications that have not been registered will not get tokens.

The first authorization mode: authorization code

In authorization Code mode, a third-party application first applies for an authorization code and then obtains a token using the code.

This approach is the most common process and the most secure, and is suitable for Web applications that have 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.

In the first step, website A provides A link, and users will jump to website B after clicking, and authorize user data to website A for use. The following is A schematic link from A to B.

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

In the above urls, the response_type parameter indicates the request to return the authorization code, the client_id parameter lets B know who is requesting the request, the redirect_uri parameter indicates the redirect URL to which B accepts or rejects the request, and the scope parameter indicates the requested authorization scope (read-only here).

Second, after the user jumps, website B will ask the user to log in, and then ask whether they agree to authorize website A. The user agrees, and site B jumps backredirect_uriParameter specifies the url. When a jump occurs, an authorization code is returned, as shown below.

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

In the above URL, the code parameter is the authorization code.

Third, after site A gets the authorization code, it can request the 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

In the above URL, the client_id and client_secret parameters are used to allow B to confirm the identity of A (the client_secret parameter is secret, so only requests can be made at the back end), and the grant_type parameter is AUTHORIZATION_CODE, The code parameter is the authorization code obtained in the previous step, and the redirect_URI parameter is the callback url after the token is issued.

Step 4: After B receives the request, it issues a token. You do this by sending a piece of JSON data to the url specified by redirect_URI.

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

In the JSON data above,access_tokenThe field is the token, and website A gets it on the back end,expires_inIs the number of expiration seconds.

The second way: hidden

Some Web applications are pure front-end applications without a back end. In this case, you can’t use the above method and must store the token in the front end. RFC 6749 provides a second approach that allows tokens to be issued directly to the front end. This approach has no intermediate step called an authorization code, so it is called “implicit.”

In the first step, website A provides A link requiring 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

In the above URL, the response_type parameter is token, indicating that the token is required to be returned directly.

In the second step, the user jumps to website B and agrees to authorize website A after logging in. In this case, site B will jump back to the redirect URL specified by the redirect_URI parameter and pass the token to Site A as the URL parameter.

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

In the above URL, the token parameter is the token, so website A gets the token directly in the front end.

Note that the token is in a FRAGMENT of a URL, not a querystring. This is because OAuth 2.0 allows URL hops to HTTP, so there is a risk of “manin the middle” attacks. When the browser hops, the anchor will not be sent to the server. The risk of token leakage is reduced.

This is not a secure way to pass tokens directly to the front end. Therefore, it can only be used in some scenarios with low security requirements, and the validity period of the token must be very short, usually during the session, and the token will be invalid when the browser is closed.

The third way: password type

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

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

In the above URL, grant_type is the authorization type, password indicates “password”, username and password are the username and password of B.

Step 2: After B website verifies 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 names and passwords, which is obviously risky. Therefore, this method is only suitable for applications where other authorization methods cannot be adopted and users have high trust.

The fourth way: credentials

The last method is client credentials, which are suitable for command line applications without a front end, requiring tokens at the command line.

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

In the URL above, the grant_type parameter is equal to client_credentials, indicating that credentials are used. Client_id and client_secret are used for B to confirm A’s identity.

Step 2: After B passes the verification, the token is returned directly.

The token presented in this way is for the third-party application, not for the user, i.e. multiple users may share the same token.

The use of tokens

After site A gets the token, it can request data from Site B’s API.

At this point, each request to the API must carry a token. This is done by adding an Authorization field to the request header, where the token resides.

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

In the command above, the ACCESS_TOKEN is the token that was obtained.

Update the token

When the token’s expiration date is up, it’s probably not a good experience to ask the user to go through the process again and apply for a new token. OAuth 2.0 allows users to update tokens automatically.

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

In the above URL, the grant_type parameter refresh_token indicates that the token is required to update, the client_id parameter and the client_secret parameter are used to confirm the identity, and the refresh_token parameter is the token used to update the token.

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

That concludes the four ways to issue a token. The next article will write a real Demo that shows how to apply a token to GitHub’s API using OAuth 2.0 and then retrieve data using the token.

(End of text)