[Full stack cultivation] OAuth2 cultivation treasure book

I. OAuth2 concept

Open Authorization (OAuth) is an open standard that allows a user to give third-party applications access to the user’s private resources (such as photos, videos, and contact lists) stored on a website without having to provide a user name and password to third-party applications. — Wikipedia

Strictly speaking, OAuth2 is not a standard protocol, but a secure authorization framework. It describes in detail how different roles in the system, users, front-end applications (such as APIS) and clients (such as websites or apps) achieve mutual authentication.

The current OAuth protocol version is OAuth2.0. It should be noted that OAuth2.0 is not backward compatible with OAuth1.0.

In daily life, the more common use scenario of OAuth2 is authorized login, and it is also widely used in the third-party services of Web, desktop and mobile apps to provide authorized login authentication mechanism, so as to achieve the right of direct data access of different applications.

Two, OAuth2 key noun introduction

The following four roles are defined in OAuth2 standard:

• Resource Owner:

Represents the User that authorizes the client to access its own resource information (User);

• Client:

Represents a third-party application that intends to access restricted resources.

• Resource Server:

Represents the server that hosts the protected user account information. It can be the same server or a different server from the authentication server.

• Authorization Server:

Represents the server that authenticates the user and then issues the resource access token to the client, that is, the server that the service provider uses specifically to handle authentication;

Three, OAuth2 operation process

1. Process analysis

(Photo by Ruan Yifeng)

The general process summary is:

• (A) Authrization Request

After the user opens the client, the client asks the user for authorization.

• (B) Authorization Grant (Get)

The user agrees to authorize the client.

• (C) Authorization Grant (Post)

The client requests a token from the authentication server by sending its own client identity and the authorization grant obtained in the previous step to the authorization server.

• (D) Access Token (Get)

After authenticating the client, the authentication server confirms that it is correct and agrees to issue the Access token. The authorization phase is over.

• (E) Access Token (Post && Validate)

The client uses the token to request resources from the resource server.

• (F) Protected Resource (Get)

The resource server validates the token and agrees to open the resource to the client.

After understanding the entire process above, let’s take a look at the following diagram to understand the entire operation process of OAuth2 more clearly:

(Picture from the road to Immortality in front of the official account)

As can be seen from the whole process, step B is the most critical step, that is, to obtain the user’s authorization for the client (for example, click the “OK” button when we scan the code to log in on wechat).

Once this authorization is in place, the client gets a token that it can use to fetch resources from the resource server.

2. Case: wechat login

In addition, the implementation process of wechat login is similar:

(Photo from official wechat document)

The overall process is as follows:

1. After a third party initiates a wechat authorized login request and a wechat user authorizes a third-party application, wechat will pull up the application or redirect it to the third-party website, and bring the code parameter of the authorized temporary note.

2. Access_token is exchanged via API with code parameter plus AppID, AppSecret, etc.

3. The access_token interface is invoked to obtain basic data resources or help users to perform basic operations.

3. Advantages and disadvantages of OAuth2

• Advantages:

Suitable for rapid development and implementation, less code, API needs to be used by different apps, and each APP uses different ways.

• Disadvantages:

The cost of learning and understanding is high, and OAuth2 is not a strict standard protocol, making it more error-prone to implement.

Four authorization modes of OAuth2

As you can see from the previous description, the core of OAuth is to issue tokens to third-party applications.

OAuth 2.0 specifies four processes for obtaining a token. You can choose the one that works best for you and issue tokens to third-party applications. The following four authorization modes are available:

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

Note:

Regardless of the authorization method, third-party applications must register with the system before applying for a token, state their identity, and then 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.

1. Authorization Code

That is, third-party applications apply for an authorization code and then use that code to obtain a token.

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.

This is also the most common process and has the highest security.

The whole process

(Photo by Ruan Yifeng)

Step analysis

1. The user jumps from website A to website B and requests the user to confirm authorization to obtain the authorization code. The link is shown as follows:

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

Among them:

The response_type parameter indicates the request to return the authorization code (code);

The client_id parameter lets B know who is requesting;

The redirect_URI parameter is the url to jump to after B accepts or rejects the request.

The scope parameter indicates the scope of authorization required (read-only in this case);

2. In website B, when the user agrees to authorize website A, website B will carry the authorization code and redirect toredirect_uriParameter specifies the url, as follows:

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

3. After website A obtains the authorization code, it requests the token from website B in the backend of website A:

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

The client_id parameter and the client_secret parameter are used to allow B to confirm A’s identity (the client_secret parameter is secret and therefore can only be requested in the back end);

The value of grant_type is AUTHORIZATION_CODE, which indicates that the authorization mode is the authorization code.

The code parameter is the authorization code obtained in the previous step;

The redirect_URI argument is the callback url after the token is issued;

4. B The website accepts the request and verifies the identity. Once authenticated, a token is issued. toredirect_uriSpecifies the url to send containing tokensaccess_tokenField JSON data, the process is complete.

They are implicit.

That is to hide the authorization code step and directly issue the token to the front end, also known as the hidden authorization code.

The whole process

(Photo by Ruan Yifeng)

Step analysis

1. When A user switches from website A to website B, user data is authorized 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

The response_type parameter is token, indicating that the token is required to be returned directly.

2. User agrees to authorize site A from Site B.

When the user agrees to authorize, it will redirect to the redirection address specified by the redirect_URI parameter and pass the token to website A as the URL parameter.

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

The token parameter is the token, so website A gets the token directly in the front end.

Note:

The token location here is the URL anchor (that is, the # number), not the query string, because the anchor is not sent to the server to avoid the risk of revealing the token.

Applicable scenarios:

Since passing tokens directly is not secure, they are often used in scenarios where security requirements are not high, and the validity of tokens is very short, such as the duration of a session, which expires when the browser is closed.

3. Password

That is, for trusted applications, you can apply for tokens with the agreed user name and password.

Process analysis

1. Website A sends A token request to website B using the user name and password provided by website B.

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

The grant_type parameter is the authorization mode, where password stands for “password”. Username and password are B’s username and password.

2. After authentication, website B will directly store the token in JSON data and return the token to website A as the CORRESPONDING HTTP.

Applicable scenarios:

High risk, generally applicable to a high level of trust in the application.

4. The client credentials

That is: give a credential for the other party to confirm and provide a token.

Process analysis

1. Application A sends A request to application B on the command line.

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

When grant_type is equal to client_credentials, the credentials are used. Client_id and client_secret are used for B to confirm A’s identity.

2. B The website authenticates the identity and returns the token.

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.

Applicable scenarios:

Request a token from the command line.

Process analysis

Use the token

Once the site gets the token, each subsequent API request needs to carry it by adding the token to the Authorization field in the request header.

Update the token

When the token expires, OAuth2 allows the user to renew the token automatically without having to reauthorize the user to obtain a new token.

Specific process:

When website B issues tokens, two tokens are issued at a time, one for obtaining data and the other for obtaining a new token (refresh Token field). After the token expires, the user uses refresh Token to send 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.

Refer to the article

1. Department internal training materials
2. OAuth 2 In Depth
3. Ruan Yifeng understands OAuth 2.0
4. Four Ways to Create OAuth 2.0 by Yifeng Nguyen