This is the second day of my participation in the August Text Challenge.More challenges in August

RFC 6749

The standard for OAuth2.0 is RFC 6794 files. This document has a detailed explanation of OAuth.

role

There are four roles defined in the RFC 6794 file

Resource Owner (resource owner)

The owner of the resource only needs to grant or deny authorization to the client.

Resource Server (resource server)

That is, a server where a service provider holds user-generated resources. Provide registration interface and open resource interface to the client. It can be the same server or a different server from the authorization server.

The client (client)

The client sends a request to the resource server to obtain the resource and an authorization request to the authorization server.

Authorization Server (authorization server)

Upon success, the authorization server issues an access token to the client, authenticates the resource owner and obtains authorization.

process

SequenceDiagram Client ->>Resource Owner: Authorization Request Resource Owner -->>Client: Authorization Grant Client ->>Authorization Server: ③ Authorization Grant Authorization Server -->>Client: ④ Access Token Client -->> Resource Owner: ⑤ Access Token Resource Owner -->>Client: ⑥ Protect Resource

① After the user opens the client, the client requires user authorization.

② The user agrees to authorize the client.

③ The client applies for a token from the authentication server using the authorization obtained in the previous step.

④ After authenticating the client, the authentication server confirms that it is correct and agrees to issue the token.

⑤ The client uses the token to apply for resources from the resource server.

⑥ The resource server confirms that the token is correct and agrees to open resources to the client.

Four authorization modes

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

Authorization code (authorization-code)

The authorization code mode is the authorization mode with the most complete functions, the most rigorous process, and the best security. The biggest difference between this mode and other modes is that the background server of the client participates in the authorization process, that is, the client must be a service with the processing capability of the background server. Authorization codes are transmitted through the front end, tokens are stored in the background server, and all communication with the resource server is done in the background server. This separation of the front and back ends prevents token leakage.

Hidden (implicit)

Implicit mode authorization does not require the backend server to participate in the process, and directly applies for a token from the authorization server in the browser, skipping the step of “authorization code”. All steps are done in the browser, the token is visible to the visitor, and the client does not require authentication. 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 this approach, allowing tokens to be issued directly to the front end.

Cryptic phone (password)

In the resource owner password credential mode, users provide their own user name and password to the client. The client uses this information to request authorization from the authorization server. 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 then uses your password to request a token.

Client credentials (client credentials)

The client mode applies when the client itself wants to interact with the authorization server as well as the resource server.

The token

Access token (Access Token)

An access token is a credential used to access a protected resource. An access token is a string that is issued to a customer. This string is usually opaque to the client. Represents the specific scope and duration of access, enforced by the resource owner, and authorized by the resource server.

Refreshing the token (Refresh Token)

The refresh token is the credential used to refresh the access token if it is invalid or expired. The refresh token is issued to the client by the authorization server, and publishing the refresh token is an optional authorization server. If the authorization server issues a refresh token, it includes the refresh token when it issues the access token, which is a string representing the client granted to the resource owner.