Oauth2.0 detailed explanation, Oauth2.0 protocol principle

Roles:

1. RO (resource owner): resource owner, a person who has the ability to authorize resources, usually likened to a user
2. RS (resource server): A resource server that stores resources and processes access requests to resources
3. Client: a third-party application. After it is confirmed by the RO, it can access the RO corresponding resources on the RS after obtaining the RO authorization
4. AS (authorization server): An authorization server that authenticates the identity of the RO, provides an authorization approval process for the RO, and finally issues an authorization token (Access Token).

PS: Usually put together with RS

Authorization mode:

Foreword: In the general authorization process, the third-party client application may be a web program or a command line code. Or some other scripts, in order to protect its security. Regarding some secret keys of users, you can choose not to expose them to users (RO). But for third-party applications, you can still access the user's data.

Support for these different types of Client, distinguishing in addition to multiple authorization modes.

1. Authorization Code Grant
2. Implicit Grant
3. RO certificate authorization (Resource Owner Password Credentials Grant)
4. Client Credentials Grant

Authorization Code Grant (Authorization Code Grant):

Typical web process:

1. The third-party application (Client) redirects the current page of the user (RO) to the authorization server (AS). After the user confirms the authorization or cancels the authorization, it is redirected back to a URL specified by the third-party web application.
2. The authorization server (AS) authenticates the user (via the http header) and determines whether the user allows third-party applications to access user resources (RS)
3. If the user confirms to authorize the third-party application, the authorization server (AS) will redirect to a url set by the third-party application in the first step and return an authorization code (that is, a temporary authentication string).
4. The third-party application passes authentication and passes the authorization code parameter obtained in the previous step, and then goes to the authorization server to verify and obtain a token.

Implicit Grant:

1. When a user accesses a third-party application (client), the third-party application redirects the user to an authorization server (AS).
2. The authorization server (AS) generates a page to provide the user with authorization
3. If the user authorizes, the authorization server (AS) returns the token to the third-party application page
4. The third-party application obtains the token returned in the previous step and goes to the resource server to obtain the user's resources (provided that the token is ok)

Password mode (Resource Owner Password Credentials Grant):

Simply put, the password is hosted to a third-party application, so here it is. We want to ensure that third-party applications are highly trusted

1. The user (RO) provides the account password to the third-party application (client).
2. The third-party application obtains the account and password from the previous step and sends a request to the authorization server
3. After the authorization server verifies that the account password is correct, it provides a token to the third-party application

Client Credentials Grant:

This is the most insecure mode, the process does not require users to participate, it is completely the communication between the third-party application and the authorization server

1. User (RO) access to third-party applications
2. The third-party application obtains the token through a custom verification method. No user authentication required
3. Access Resource Server (RS)