1. What is OAuth?

OAuth, short for Open Authorization, is an Open Authorization standard. It allows users to give third-party applications access to the user’s private resources stored on a site (such as photos, videos, and contact lists) without having to provide a user name and password to third-party applications.

OAuth allows users to provide a token, rather than a username and password, to access the data they store with a particular service provider. Each token grants a specific site (for example, a video editing site) access to a specific resource (for example, just a video in a photo album) for a specific period of time (for example, the next 2 hours). In this way, OAuth lets users authorize third-party sites to access specific information they store with another service provider, but not all of it. Therefore, OAuth is safe.

OAuth2.0 is a continuation of the OAuth protocol, but is not forward compatible (i.e., OAuth1.0 is completely abolished).

In layman’s terms, OAuth is an authorization mechanism that authorizes third-party applications to access specific user data.

2. Its members

  1. Resource Owner: Indicates the Resource Owner
  2. Resource Server: An application that holds the (protected) resources of the Resource owner
  3. Client: the application that needs to access the resources of the resource owner on the resource server
  4. Authorization Server: the Authorization Server on the system where the resource Server resides is responsible for the access and Authorization of the system resources
  5. User-agent: A User agent object that helps you access resources. It is usually a browser on a PC or an App or small program on a mobile terminal

3. What can OAuth2.0 do?

  1. Third party login (wechat login, QQ login, etc., which can also be regarded as obtaining the user’s specific resources on an application)
  2. Gets a specific resource that a user has saved on an application

** Pain points addressed: ** How to allow untrusted third parties to access user-hosted resources without causing damage.

4. So, how does OAuth2.0 authorize?

In general, OAuth2.0 has four types of authorization:

  1. Authorization Code

  2. Simplified patterns (Implicit)

  3. Password mode (Resource owner Password Credentials)

  4. Client credentials

    ​

A general process:

Popular description:

(Lao Li asks Lao Zhao to fetch the two old men he has hidden in the second Battalion commander’s warehouse.)

** Step 1: ** Lao Zhao said you asked me to get the wine, but the little bastard in the second battalion commander didn’t trust me, so you gave me a note (the client asked the resource owner for authorization)

** Step 2: ** Lao Li said it was easy, so he asked the guard to write a note and sign it in large letters (the authorization here is given by the authentication server with the permission of the resource owner).

** Step 3: ** Lao Zhao took the note to find the second battalion commander to get wine (the client with the user to give the authorization certificate, to the authentication server to initiate a request to obtain access to resources)

** Step 4: ** The second battalion commander looked at the note in Lao Zhao’s hand and said, “All right, the wine is in the cellar of our camp, you wait, I will give you a temporary pass, you go to the cellar to get the wine” (the authentication server verifies the certificate and grant the temporary access token for corresponding resources).

** Step 5: ** Lao Zhao takes the temporary pass to the wine cellar to get the wine (the client brings the access token to request the resource server to get the resource)

** Step 6: The guards of ** wine cellar checked the token in Lao Zhao’s hand, confirmed it was correct, and gave Lao Zhao the wine. (The resource server verifies the access token sent by the client and returns the corresponding resource if it passes)

** Off topic: ** Lao Li in the process of waiting for Lao Zhao to take wine, thinking that there are still two drinks, then put on the last attack on the Devil convoy captured the ana clothes to pingan County city shun back half a roast chicken… (CSRF attack on OAuth, interested readers can go to know)

4.1 Authorization Code Mode (Authorizatiion Code)

4.1.1 Basic process

** Note: ** The client of service A needs to obtain resources from service B

Basic process:

(The user has permissions for application A and application B.)

Step 1: The Resource Owner requests application A to access the resources on application B through the user-Agent

Step 2: Application A redirects user requests to application B’s authentication service page (this step requires application A to provide A callback address so that application B’s authentication service returns an authorization code)

Step 3: The user logs in and clicks the grant button to allow application A to access user B’s resources.

Step 4: The Authorization Server of application B generates an Authorization code and returns the code to application A using the callback address provided by application A

Step 5: The authentication server (Client) of application A requests the authorization server of application B with the authorization code to obtain the resource access permission

Step 6: Apply the authorization server of B to verify the authorization code and issue the resource access token to the client

Step 7: The client takes the access token to the Resource Server to request the corresponding Resource

** Features: ** Tokens are issued to third-party application authentication servers (clients), not exposed to browsers.

4.1.2 Application Scenarios:

Authorization code mode is the most secure and perfect mode in OAuth2, with the most extensive application scenarios. It can realize the invocation between services, and common Third-Party login such as wechat and QQ can also be realized in this way.

4.2 Simplified Patterns (Implicit)

The simplified mode is a simplification of the authorization code mode by removing the authentication server for third-party applications and sending tokens directly to the browser (user proxy object).

4.2.1 Basic process

Step 1: The Resource Owner requests application A to access the resources on application B through the user-Agent

Step 2: Application A redirects user requests to application B’s authentication service page (this step requires application A to provide A callback address so that application B’s authentication service returns an authorization code)

Step 3: The user logs in and clicks the grant button to allow application A to access user B’s resources.

Step 4: The Authorization Server of application B generates the Authorization code and returns it to the user proxy object (also equivalent to the client) using the callback address provided by application A.

Step 5: The client requests the authorization server of application B with the authorization code to obtain the permission to access the corresponding resources

Step 6: Apply the authorization server of B to verify the authorization code, and issue the resource access token and update token to the client

Step 7: The client takes the access token to the Resource Server to request the corresponding Resource. If the access token is out of date, the client takes the update token to the authorization Server to re-issue the access token.

4.2.1 Application Scenarios

This works for third-party applications without a server, such as applets

* Personal advice: * Do not expose the token in the browser if you can avoid it.

4.3 Resource Owner Password Credentials

4.3.1 Basic process

The resource owner directly tells the third-party application the account and password, and the third-party application uses the account and password of the resource owner to access the corresponding resource.

4.3.2 Application Scenarios

The client is very trusted (the third party is never trusted. It can be said that OAuth protocol is created to solve the problem of protected resource access under the background of untrusted third parties.

4.4 Client Credentials

This mode is actually out of the scope of the OAuth protocol, purely client and resource server application interaction.

4.4.1 Basic process

Step 1: The client requests the token from the authorization server. Step 2: The authorization server returns the token to the client.

4.4.2 Application Scenarios

Service A, where the client resides, requires the resources of service B, regardless of the user.