GB/T 47475-2026Cybersecurity technology - Open resource authorization protocol for third parties (English PDF)

5.3 Protocol Endpoint Types

5.3.1 Endpoint Classification This document specifies three functional endpoints.

a) Authorized endpoint;

b) Token endpoint;

c) Redirect endpoints. Authorization endpoints and token endpoints allow clients to add parameters to their requests that indicate the scope of access, specifying the resource access request. The request specifies the scope of protected resource access. Accordingly, the authorization server informs the client by including the access scope parameter in the response. The response specifies the scope of protected resource access granted by the issued access token. If the actual granted access scope differs from the requested scope, the response will provide... A parameter that indicates the actual scope of access, informing the client of the scope of protected resources that are actually allowed to be accessed. If the client omits the scope parameter when requesting authorization, the authorization server responds to the request with a predefined default value, or rejects it. This request. The authorization server describes the requirements and default values for the range parameters in its service documentation.

5.3.2 Authorized Endpoints The authorization endpoint resides on the authorization server, receiving authorization requests from clients, the resource owner's identity credentials and authorization, and authorizing the process via user proxy. The client is redirected to the redirect endpoint along with an authorization code. When the authorization server receives the client's authorization request, the authorization server first... First, verify the identity of the resource owner. The authorization endpoint URI is typically provided by the authorization server's service documentation. The URI of the authorized endpoint may contain a query component. When additional query parameters are added, this query component is retained, and the endpoint URI does not contain it. Fragment component. The authorization endpoint of the authorization server should be capable of handling HTTP GET requests and should also be able to handle HTTP POST requests. ability.

5.3.3 Token Endpoint The client submits an authorization or refresh token to the authorization server's token endpoint. After verifying the request, the authorization server issues the token via the token endpoint. Give the access token to the client. This document does not specify how the client obtains the token endpoint URI (this is usually provided by the authorization server's service documentation). The token endpoint URI may contain a query component. This query component is retained when additional query parameters are added. The token endpoint URI does not contain... Includes fragment components. The client uses the HTTPPOST method when requesting an access token from the token endpoint of the authorization server. When the authorization server's token endpoint receives a request from a client with credential protection or other clients that have been granted identity credentials... When a request is made, the authorization server authenticates the client's identity.

5.3.4 Redirecting Endpoints During its registration phase, the client pre-registers the URI with the authorization server as a redirect endpoint. The authorization server then completes the process with the resource owner. After the interaction with the user, the resource owner's user agent is redirected to the client's redirection endpoint, and the authorization result is returned to the client. The redirect endpoint URI is an absolute URI. The redirect endpoint URI can contain query components; additional information can be added to the redirect endpoint URI. When querying parameters, retain this component. Redirect endpoint URIs do not contain fragment components. The security requirements for redirected endpoints should comply with B.2.

6.4 Identity Verification

6.4.1 Identity Authentication Scheme For clients with credential protection capabilities, when the authorization server uses an identity credential-based authentication scheme to authenticate the client... At that time, the authorization server should allow the client to add relevant parameters to the request body to pass the client's identity credentials for authentication. The client uses the HTTP Basic Authentication scheme (see RFC 9110). When using an authentication scheme that includes client credentials in the request body... When transmitting parameters, the following parameters should be placed in the HTTP body using the POST method, and should not be transmitted using the HTTHGET method. Included in the requested URI. The client identifier described in 6.2.

b) client_secret [Required] Client key.

c) nonce [Required condition] A random string generated by the client. This parameter is required when client_secre uses the method described in

d) timestamp [Required] Timestamp. This parameter is required when client_secre uses the method described in

Note 2. Since the method of identifying clients with credential protection capabilities involves client keys, the authorization server should take measures to ensure that all such clients are protected. The endpoint of the client key is designed to withstand brute-force attacks. Client authentication security requirements should comply with B.3.

6.4.2 Digital Certificate Authentication Scheme This document recommends using a digital certificate authentication scheme to verify the identity of clients. For clients that support domestically developed cryptographic algorithms... If a digital certificate authentication scheme is explicitly adopted during the client registration phase, an SM2 digital certificate conforming to GB/T 32918.2 should be used. For client authentication, the two-way authentication scheme in GB/T 15843.3 should be adopted. Client identity authentication security. The requirements should comply with B.3.

6.4.3 Other identification methods The authorization server may employ any authentication scheme that meets its security requirements. When using other authentication schemes, the authorization server should record... The authentication scheme corresponding to the client identifier.

7.1 License Type

7.1.1 Overview This document specifies three types of licenses.

a) Authorization code license;

b) Client identity credential permission;

c) Equipment licensing.

7.1.2 Authorization Code Licensing The client does not request authorization directly from the resource owner; instead, it requests authorization from the resource owner through an authorization server. The resource owner's user agent is redirected to the authorization server. The authorization server interacts with the resource owner to verify the resource owner's identity. After verifying the identity and obtaining authorization from the resource owner, the user agent of the resource owner is redirected back to the client, and the redirection message carries the authentication information. Includes authorization code. The authorization code licensing process is applicable to applications that require authorization from the resource owner, where the client, on behalf of the resource owner, accesses protected resources. Use cases. For clients without credential protection capabilities, an authorization code licensing process should be used; for clients with credential protection capabilities... It is advisable to use the authorization code licensing process. The authorization code licensing type can be used to obtain access tokens and refresh tokens.

7.1.3 Client Identity Credentials Permission Client identity credentials (or other forms of information that can be used for client authentication) can be used as authorization to obtain access tokens. Client identity credential authorization is a method of authorization in restricted scenarios. Client identity credential authorization types are applicable to the following... Limited to specific scenarios.

a) Scenarios where the protected resources are controlled by the client;

b) Scenarios where, through negotiation, the authorized server agrees to allow the client to access protected resources.

7.1.4 Equipment Licensing Device licensing is a method for authorizing input-restricted devices such as smart TVs and printers. The license allows users to complete the authorization process through devices equipped with standard web browsers (such as smart mobile communication terminals).

7.2 Authorization Code Licensing

7.2.1 Process The authorization code licensing process is shown in Figure 2.

7.2.2 Authorization Request The client constructs an authorization request by adding the following parameters to the query component of the authorization endpoint URI.

7.2.1

b) After the resource owner confirms the authorization, the authorization server issues an authorization license to the client based on the authorization intention.

c) The client submits authorization and identity credentials to the authorization server and requests an access token from the authorization server.

d) The authorization server authenticates the client's identity and verifies the validity of the authorization license. If the client's identity authentication is successful and the authorization license is valid... If valid, the authorization server issues an access token to the client.

e) The client sends an access token and related parameters to the resource server to request access to the protected resource.

f) The resource server verifies the validity of the access token. If the access token is valid, the requested resource is sent to the client, such as the client... If the client's access to the protected resource exceeds the access token's range or validity period, the access becomes invalid, and the client must re-establish the authorization request. Access token refresh is performed according to the provisions of 8.3. The basic protocol flow mainly consists of two phases. authorization and access to protected resources. For details on the authorization process, please refer to Chapter 7, Resource Access. See Chapter 9. The authorization protocol specified in this document is built upon HTTP. See Appendix A for protocol parameter descriptions. Protocol channel security requirements should comply with... B.1.

7.3 Client Identity Credentials Permission

7.3.1 Process The client identity credential authorization process is shown in Figure 3. Figure

3 Client Identity Credentials Authorization Process Figure 3 includes the following steps.

a) The client sends an access token request to the authorization server's token endpoint and submits the client's identity credentials. The authorization server then grants the client access tokens. Client-side identity verification;

b) The authorization server authenticates the client's identity. If the authentication is successful, an access token is issued. The security requirements in the client identity credential authorization process should comply with B.5.

7.3.2 Authorization Requests and Responses The client authentication result is used for authorization, without the need for additional authorization requests.

7.3.3 Access Token Request The client sends a request to the token endpoint, adding the following parameters to the request body (the parameters are UTF-8 encoded before use). (encoded in "application/x-www-form-urlencoded" format)

a) grant_type [Required] The parameter value is "client_credentials";

b) client_id [Required] The client identifier described in section 6.2;

c) Scope [Optional] Request access to the scope of the protected resource. The authorization server authenticates the client's identity according to the authentication method given in 6.4.

7.3.4 Access Token Response If the access token request is valid, the authorization server issues an access token as described in 8.2.1, and the response should not include a refresh token. If the authorization server fails to authenticate the client that initiated the access token request, or fails to verify the client's request, then the authorization server... Return the error response described in 8.2.3.

7.4 Equipment Licensing

7.4.1 Process The equipment authorization and licensing process is shown in Figure 4. Figure

4 Equipment Licensing Process Figure 4 includes the following steps.

a) The device's client requests access rights from the authorization server, and includes the client identifier in the request.

b) The authorization server issues a device code, user code, and user authentication URI to the device's client.

c) The device's client instructs the user to access the provided user authentication URI using a user agent on another device, and provides the user with... Provides end-user codes.

d) The authorization server authenticates the end user through the user agent and prompts the user to enter the username and password provided by the device's client. User code. The authorization server verifies the user code provided by the user and prompts the user to accept or reject the request.

e) During the end-user's review of the client's authorization request [step d)], the client repeatedly polls the authorization server to determine if the user is... Has the user authorization process been completed? The polling request contains the device code and its client identifier.

f) The authorization server verifies the device code provided by the client and responds to the access request when the client is granted access rights. The token, if access is denied, returns an error or instructs the device's client to continue polling. The security requirements in the equipment licensing mechanism should comply with B.6.

7.4.2 Authorization Request The client sends an HTTP "POST" request to the device authorization server, which includes the following parameters.

a) client_id [Required] The client identifier described in 6.2;

b) Scope [Optional] Request access to the scope of the protected resource.

7.4.3 Authorization Response

7.4.3.1 Correct Response The authorization server generates a unique device code and user code, and adds them to the HTTP response body. The response parameters are as follows:

a) device_code [Required] Device code;

b) user_code [Required] User code;

c) verification_uri [Required] Validate URI;

d) verification_uri_complete [optional] An authentication URI containing a user code (or other information that serves the same function as a user code), used for non-text transmission;

e) expires_in [Required] The validity period of the device code and user code is in seconds;

f) interval [optional] The minimum time the client should wait between polling requests to the token endpoint. If this parameter is not included in the response, the default value is [default value]. 5s.

7.4.3.2 Error Response If an error occurs, the authorization server sends an error response to notify the client of the reason for the error.

a) error [Required] Error codes, error code types are as follows: 1) `invalid_request` indicates that a required parameter is missing, an invalid parameter exists, or a parameter is included repeatedly in the request. The number, or other form of formatting error; 2) invalid_client indicates that client authentication failed; 3) invalid_grant indicates that the provided license is invalid, expired, revoked, does not match the redirect endpoint URI, or that... The license was not issued to the current client; 4) `unauthorized_client` indicates that the client is not authorized to request an authorization code using the current method; 5) `unsupported_grant_type` indicates that the client is not authorized to use the current license type; 6) invalid_scope indicates that the requested resource access scope is invalid, unknown, or inappropriate. The value of the error parameter does not contain characters outside the %x20-21/%x23-5B/%x5D-7E set.

b) error_description [optional] End-user readable ASCII text, providing additional information to help client developers understand errors that have occurred. This parameter The value does not contain characters outside the %x20-21/%x23-5B/%x5D-7E set.

c) error_uri [optional] This parameter is used to identify a webpage containing more information about the error that is readable by the end user. The value of this parameter conforms to the URI-ref- The syntax should be consistent and should not contain characters outside the %x20-21/%x23-5B/%x5D-7E set.

8.1 Token Types

8.1.1 Access Token An access token is a credential issued by an authorization server to a client to access protected resources. Access tokens are represented by strings, and... The client has obtained authorization from the resource owner. Access tokens are typically difficult for the client to interpret. The access token provides... The scope and validity period of access to protected resources are authorized and agreed upon by the resource owner and managed by the resource server. And the authorization server is implemented. Access tokens can serve as identifiers for retrieving authorization information, or they can contain authorization information itself. The authorization information contained in the access token can be retrieved through a certain... Verification is achieved through various methods (e.g., including data and signature). This document recommends that authorization servers prioritize those conforming to GB/T 32905. The SM3 algorithm performs a hash operation on the access token content, and then uses the SM2 algorithm conforming to GB/T 32918.2 or other related algorithms for further processing. The signature is then encrypted using the SM4 algorithm conforming to GB/T 32907 or other relevant algorithms. The token is sent out. The access token contains the necessary information required for the client to request the protected resource. Each access token type should be defined by a corresponding specification. If a client cannot recognize a certain access token type, it should not use it. Tokens. When the definition of an access token type includes extended parameters beyond those specified in 8.2.2, the verification method for the access token should also be specified. This document does not specify the method for resource servers to verify the validity of access tokens. Access token security requirements should comply with B.7.