OAuth (Open Authorization) is an open standard that allows users to authorize third-party applications to access their information stored on another service provider without having to provide user names and passwords to third-party applications or share all the content of their data. OAuth2.0 is a continuation of the OAuth protocol, but it is not compatible with OAuth1.0, that is, OAuth1.0 is completely abolished. Many large companies such as Google, Yahoo, Microsoft and others provide OAUTH authentication services, which is enough to show that OAUTH standard is becoming the standard of open source authorization

Oauth protocol has been developed to version 2.0. Version 1.0 is too complex, and version 2.0 has been widely used.

Reference: baike.baidu.com/item/oAuth/…

Request: tools.ietf.org/html/rfc674…

Oauth2 authentication process

  • The flow chart

Quotations from OAauth2.0 agreement rfc6749 tools.ietf.org/html/rfc674…

  • Concept:

    • The client

      It does not store resources, and needs to request resources from the resource server through the authorization of the resource owner, such as: Android client, Web client (browser), wechat client, etc.

    • Resource owner

      Usually the user, or the application, that is, the owner of the resource.

    • Authorization server (also known as authentication server)

      The access_token is used by the service provider to authenticate the identity of the resource and authorize the access to the resource. After the authentication is successful, the access_token is issued to the client as the credential for the client to access the resource server. L For example: wechat authentication server, Alipay authentication server

    • Resource server

      Servers that store resources, such as wechat and Alipay, can obtain user information saved by wechat and Alipay through access_Token after being authenticated by the authentication server

Four modes of Oauth2

Authorization code mode

In simple terms, the user is authorized to get the code, and then through the code to the authentication server to get access_otken

  • The certification process

  • The process that

    • The resource owner opens the client, which requests authorization from the resource owner. The client redirects the browser to the authorization server, with the client’s identity information attached to the redirect. Such as:

      /server/oauth2/authorize? client_id=test&response_type=code&scope=app&redirect_uri=http://xx.xx/notify
Copy the code

      Client_id: indicates the client access ID.

      Response_type: specifies the authorization code mode. This parameter is fixed to code.

      Scope: client permission.

      Redirect_uri: indicates the forward URI. If the authorization code is applied successfully, the IP address is forwarded to and the code parameter (authorization code) is followed. For example: xx xx/notify? Code…

    • The browser appears to grant authorization to the authorization server, and then the user agrees to grant authorization.

    • The authorization server sends the AuthorizationCode to the client via the browser (via redirect_uri, concatenated parameters after the url).

    • The client requests access to the access_token from the authorization server with the authorization code:

      /server/oauth2/token? client_id=test&client_secret=gdjbcd&grant_type=authorization_code&code=qwe12&redirect_uri=http://xx.xx/notify
Copy the code

      Client_id: indicates the access id of a client.

      Client_secret: indicates the client secret key.

      Grant_type: specifies the authorization type. Enter authorization_code, which indicates the authorization code mode. Code: specifies the authorization code that you have just obtained.

      Redirect_uri: indicates the redirect URL used when applying for an authorization code. It must be the same as the redirect_URI used when applying for an authorization code

    • Authorization server returns token (access_token)

This mode is the safest of the four modes. It is used when a Web server application or a third-party native App invokes a resource service. In this mode, access_token is not exchanged through the browser or mobile App, but directly from the server, which minimizes the risk of token leakage

Password mode

Password mode is widely used and is suitable for first-party single-page applications and first-party native apps

  • The certification process

  • Process description:

    • The resource owner sends the user name and password to the client or third-party system.

    • The client requests the access_token from the authorization server with the user name and password of the resource owner. The request is as follows:

      /server/oauth2/access_token? client_id=web&client_secret=123321&grant_type=password&username=shanghai&password=123456
Copy the code

      Client_id: indicates the access id of a client.

      Client_secret: indicates the client secret key.

      Grant_type: authorization type. Password indicates the password mode

      Username: indicates the username of the resource owner.

      Password: indicates the password of the resource owner

    • The authorization server sends the access_token to the client

This pattern is very simple, but means that sensitive user information is directly exposed to the client, so this pattern can only be used if the client is developed by us. So password mode is generally used for our own, first-party native apps or first-party single-page apps or trusted third party systems.

Client mode

  • The certification process

  • The process that

    • The client sends its identity information to the authorization server and requests an access_token.

    • After confirming the client’s identity, the access_token is sent to the client with the following request:

      /server/oauth2/access_token? client_id=test&client_secret=123321&grant_type=client_credentialsCopy the code

      Client_id: indicates the access id of a client.

      Client_secret: indicates the client secret key.

      Grant_type: authorization type. Client_credentials indicates the client mode. This mode is the most convenient but least secure. Therefore, this requires complete trust in the client, and the client itself is also secure. For this reason, this pattern is generally used to provide server-side services that we trust completely. For example, the partner system docking, pull a group of user information

Client-side mode is adapted to access server-side programs without user participation by fully trusted parties or partners.

The client mode is similar to the password mode. You can obtain an access_token through a process. The two simple authentication modes can be directly applied to a client or a third-party system

Simplify the model

  • The certification process

  • The process that

    • The resource owner opens the client, which requests authorization from the resource owner. The client redirects the browser to the authorization server, with the client’s identity information attached to the redirect. Such as:

      /server/oauth2/authorize? client_id=test&response_type=token&scope=app&redirect_uri=http://xx.xx/notify
Copy the code

      Parameter Description Response_type =token indicates the simplified mode. Indicates that access_token is directly required

    • The browser appears to grant authorization to the authorization server, and then the user agrees to grant authorization

    • The authorization server hashes the access_token to fargment in the redirect URI and sends it to the viewer.

      Note: A fragment is used to identify a resource in the resource identified by the URI. The fragment is preceded by (#) at the end of the URI, where # is not the fragment value. For example, https://domain/index#L18, the URI L18 is the fragment value. All you need to know is that JS can get fragments in response to changes in the browser’s address bar

Generally, the simplified mode is used for third-party single-page applications. In this mode, only the front end can complete the authentication process without interaction with the back end. Therefore, the simplified mode is generally applied to single-page front-end applications such as VUE and React that are separated from the front end and can directly obtain the Access_token.

Certification center

In microservices, if there is a need for certification, there must be a unified certification center. The following is the process of microservices and certification center

  • The certification process

  • The process description

    (1) Access party (collectively referred to as access Party if it needs to use platform resources) adopts OAuth2.0 mode to request unified Authentication Service (UAA) for authentication. (2) The authentication service (UAA) invokes the unified account service to query the user information and its permission information. (This step is not required for third-party application access.)

    (3) Authentication service (UAA) verifies the validity of login users and third-party applications.

    (4) If the identity of the access party is legal, the authentication service generates a JWT token and returns it to the access party, in which JWT contains permission information. (5) The access party carries the JWT token to access the micro-service resources within the API gateway.

    (6) THE API gateway parses the token and verifies whether the access party’s permission can access the requested micro-service. (7) If the access party has no problem, the API gateway forwards the Token to the micro service.

    (8) When the micro-service receives the request, the plaintext token contains the identity and permission information of the login user, and the subsequent micro-service uses the identity and permission information of the user.

  • Service responsibilities

    • Unified Account Service

      Provides system-level information management for merchants and platform operators, including login accounts, passwords, roles, permissions, and resources, excluding user business information.

    • Unified Authentication Service (UAA)

      It bears the responsibility of OAuth2.0 access party authentication, login user authentication, authorization and token generation, and completes the actual user authentication and authorization functions.

    • API gateway

      As a unique entry point to the system, the API gateway provides access parties with a custom set of apis, which may also have other responsibilities such as authentication, monitoring, load balancing, caching, and so on. The core point of THE API gateway approach is that all access parties and consumers access microservices through a unified gateway and handle all non-business functions at the gateway layer.

Welcome to the wechat public account “code on the finger tip”

Original is not easy, click a praise and then go ~ welcome to pay attention to, to bring you more wonderful articles!

Your likes and attention are the biggest motivation for writing articles