HOME   Cart(0)   Quotation   About-Us Tax PDFs Standard-List Powered by Google www.ChineseStandard.net Database: 189759 (9 Feb 2025)

GM/T 0069-2019 PDF English


Search result: GM/T 0069-2019 English: PDF (GM/T0069-2019)
Standard IDContents [version]USDSTEP2[PDF] delivered inName of Chinese StandardStatus
GM/T 0069-2019English690 Add to Cart 0-9 seconds. Auto-delivery. Open identity authentication framework Valid
BUY with any currencies (Euro, JPY, GBP, KRW etc.): GM/T 0069-2019     Related standards: GM/T 0069-2019

PDF Preview: GM/T 0069-2019


GM/T 0069-2019: PDF in English (GMT 0069-2019)

GM/T 0069-2019 GM CRYPTOGRAPHIC INDUSTRY STANDARD OF THE PEOPLE’S REPUBLIC OF CHINA ICS 35.040 L 80 Open identity authentication framework ISSUED ON: JULY 12, 2019 IMPLEMENTED ON: JULY 12, 2019 Issued by: State Cryptography Administration Table of Contents Foreword ... 4  Introduction ... 5  1 Scope ... 6  2 Normative references ... 6  3 Terms and definitions ... 7  4 Abbreviations ... 11  5 Overview ... 12  6 Entity requirements ... 14  6.1 Requirements for identity service providers ... 14  6.2 Requirements for relying party ... 17  7 Identification process ... 19  7.1 Identification process type ... 19  7.2 Authorization code authentication process ... 20  7.3 Implicit authentication flow ... 36  7.4 Hybrid authentication flow ... 41  7.5 Access token refresh mechanism ... 47  8 Token ... 49  8.1 Token type ... 49  8.2 JSON token ... 52  8.3 Token security protection requirements ... 55  9 User information access ... 57  9.1 Types of claims ... 57  9.2 Language and writing claim ... 60  9.3 User information endpoint ... 60  9.4 User information request claim ... 63  9.5 Stability and uniqueness of claim ... 67  10 Signature and encryption requirements ... 68  10.1 Overview ... 68  10.2 Signature ... 68  10.3 Encryption ... 69  10.4 Entropy of symmetric key ... 71  10.5 Order of signature and encryption ... 71  Appendix A (Normative) Normal claim ... 72  Appendix B (Informative) Basic configuration of identity service provider ... 74  Appendix C (Informative) Relying party's registration information ... 77  References ... 80  Open identity authentication framework 1 Scope This standard specifies the agreement framework for relying parties (network applications or services) to use the authentication function provided by the identity service provider to authenticate end users; defines the requirements of the entities involved in the agreement, the authentication protocol process, the access requirements of user information, as well as the encryption and signature requirements of protocol messages, etc. This standard applies to the development, testing, evaluation and procurement of user identification services in scenarios where end users access network applications. 2 Normative references The following documents are essential to the application of this document. For the dated documents, only the versions with the dates indicated are applicable to this document; for the undated documents, only the latest version (including all the amendments) are applicable to this standard. GB/T 32905-2016 Information security technology SM3 cryptographic hash algorithm GB/T 32907-2016 Information security technology - SM4 block cipher algorithm GB/T 32918.2-2016 Elliptic curve public - Key cryptography - Part 2: Digital signature algorithm GB/T 32918.4-2016 Elliptic curve public - Key cryptography algorithm - Part 4: Public - key encryption algorithm GM/T 0024-2014 SSL VPN specification GM/T 0068-2019 Open third party resource authorization protocol framework ISO 639-1 Codes for the representation of names of languages - Part 1: Alpha-2 code ISO 3166-1 Codes for the representation of names of countries and their subdivisions - Part 1: country codes ISO 8601:2004 Data elements and interchange formats - Information interchange - Representation of dates and times ISO/IEC 29115:2013 Information technology - Entity authentication assurance framework RFC 1867 HTML Form-based file upload in HTML RFC 3966 The tel URI for telephone numbers RFC 3986 Uniform resource identifier (URI): Generic syntax RFC 4627 The application/json media type for JavaScript object notation (JSON) RFC 5322 Internet message format RFC 5646 Tags for identifying languages RFC 6125 Representation and validation of domain-based application service identity within Internet public key infrastructure using X.509 (PKIK) certificate in the context of transport layer security (TLS) E.164 The international public telecommunication numbering plan 3 Terms and definitions The following terms and definitions apply to this document. 3.1 Access token The token issued by the authorization server, which is used to prove that an entity has the authority to access protected resources within a specific range. 3.2 Authentication request A request for the purpose of authenticating the identity of the end user. Note: After the identity service provider receives the request sent by the relying party, it authenticates the terminal user. 5 Overview The identity authentication protocol framework specified in this standard allows the relying party to use the authentication service of the identity service provider to authenticate the end user. After the end user is successfully authenticated, the relying party can obtain the authorized user’s identity information from the identity service provider. The identity authentication protocol framework specified in this standard mainly involves three types of participating entities: relying parties, identity service providers, end users. This standard mainly regulates the functions of relying parties and identity service providers: - Relying party: When the relying party is accessed by an end user, the relying party shall authenticate the end user. For end users who have not yet been authenticated, the relying party selects an identity service provider to authenticate the end user; - Identity service provider: Authenticate the end user; ask the end user who is successfully authenticated about the authorization of the relying party to access the user's identity information. After the end user is authorized, the authorized user’s identity information is finally sent to the relying party, to complete identity authentication. Among them, the authorization server of the identity service provider realizes the identification of the end user's identity. The authorization server contains two functional interfaces: an authorization endpoint and a token endpoint. The identity service provider realizes the access of the relying party to the user information by providing the user information endpoint. Endpoints are identified by URI. The typical format of the URI is: [scheme:][//hostname (authority)][path(path)][? query component (query)][#fragment component (fragment)]. The query component and fragment component use the encoding format of "application/x-www-form-urlencoded" (see RFC 1867). The interaction between the relying party, the identity service provider, and the end user shall use cryptographic technology to ensure security. Both the relying party and the identity service provider shall carry out relevant configurations to support the agreement. This standard regulates the entity requirements of the relying party and the identity service provider (see Chapter 6). When a terminal user accesses a service provided by a relying party, if the relying party requires the end user to be authenticated and supports the protocol defined in this standard, the relying party can redirect the end user to an identity service provider trusted by the relying party and execute the information. By using a security token, it is possible to avoid sharing the identity credentials of the end user with the relying party, to securely present the identity information of the end user to the relying party. In order to ensure the security of the token and its use security, this standard defines and gives the security requirements of the token. In the process of the relying party presenting the access token to the identity service provider and obtaining user information, this standard gives specific definitions and requirements for the use of tokens to access user identity information, mainly involving the claim of the entity transmitted in the protocol and user information endpoint requirements, etc. Finally, this standard provides the signature and encryption requirements to ensure the protocol security. In addition, this standard also supports some less commonly used methods of initiating identity authentication. Under normal circumstances, the identity authentication service is initiated by the relying party to the identity service provider. But in some cases, identity authentication may be initiated by the identity service provider or other entities. For example, a user who is using identity service provider A accesses the shopping page of application B (relying party) through a link on the page of A; A directly initiates an identity authentication process to an unidentified user. In this case, identity authentication is not directly initiated by the relying party B. In addition, under normal circumstances, access to user information requires real-time authorization by the end user. After the user is authorized, the relying party can obtain the authorized user information. This standard also supports user information access when the end users are offline; it does not require online real-time authorization by users. For example, the end user can pre-authorize the identity service provider and configure the access authority of the relying party, so that the relying party does not require the user to perform real-time online authorization when requesting user information from the identity service provider. However, for offline user information access, due to security risks, it shall be used with caution. 6 Entity requirements 6.1 Requirements for identity service providers 6.1.1 Overview The identity service provider is an entity that provides identity authentication services for end users who access the relying party and shall provide the following functions: 6.1.3 Requirements for security configuration protocol The identity service provider shall provide the necessary basic configuration (see Appendix B) to implement the protocol process. First, the identity service provider shall provide the issuer identifier (usually URI), so that the relying party can find the identity service provider when executing the identity service discovery protocol. Secondly, it shall configure and provide the URI of the authorization endpoint, the URI of the token endpoint, the URI of the encryption and signing token key, the response type, the response parameters, etc.; provide the method of configuration information that the relying party shall know. This standard assumes that the relying party has already obtained the configuration information of the identity service provider. The relying party can obtain this information through the automatic discovery process or other methods. This standard does not specify the specific automatic discovery process or other methods of discovering identity services. Among them, the issuer identifier is an identifier used to identify the identity service provider. This standard supports multiple issuers; the combination of each host and port is an issuer; the combination of multiple hosts and ports can realize multiple issuers. In general, this standard requires that each host supports only one issuer. However, if the host supports multiple tenants, it may need to support multiple issuers. The issuer identifier returned through the discovery process shall exactly match the < iss> parameter value of the ID token (see 8.1.2). The issuer identifier shall correspond exactly to the user's subject identifier. Even if the subject names of two end users are the same, but the issuer identifier is different, they shall be regarded as two different users. 6.1.4 Requirements for secure transmission and processing of protocol messages The identity service provider shall provide a secure identity authentication method so that: the relying party can authenticate the identity service provider, thereby preventing malicious servers from disguising as legitimate servers; for relying parties with confidentiality capabilities, the identity service provider shall provide the method of identifying the relying party, thereby preventing the malicious relying party from impersonating the legitimate relying party to obtain user information. The identity service provider shall establish a secure session with the relying party. It shall use the secure communication protocol as defined in the SSL VPN technical specification GM/T 0024-2014 for communication. In the process of establishing a secure connection with the relying party, the identity service provider shall bind its full domain name to its public key, so that According to whether the relying party has the ability to keep its identity credentials confidential, this standard defines two types of relying parties: a) Confidentiality type The relying party has the ability to maintain the confidentiality of its credentials (for example, the relying party’s application runs on a secure server that strictly enforces access control), so that it can prove the authenticity of its identity by providing secure identity credentials, or the relying party has the ability to prove the authenticity of the identity through other means (outside the scope of this standard). b) Non-confidentiality type The relying party is unable to maintain the confidentiality of its credentials (for example, the relying party’s program runs on the device used by the resource owner, local application or browser-based application, etc.); it cannot provide secure identity credentials to prove the authenticity of its identity; meanwhile it has no ability to prove the authenticity of their identity through other means. The identification of the type of the relying party depends on the identity service provider’s authentication security requirements and the acceptance level of the relying party’s credential exposure level (usually provided by the identity service provider’s service documentation). The authorization server shall not make assumptions about the type of relying party. 6.2.3 Requirements for relying party’s registration and protocol configuration When the relying party uses the identity authentication service of the identity service provider, it shall register the necessary protocol parameters with the identity service provider, for example, provide the redirect URL address for receiving messages, homepage URL address, contact information, relying party type, supported methods for identifying the identity of the relying party and other information (see the registration information as described in Appendix C). When the registration is successful, the relying party will obtain the following parameter value pairs representing identity credentials from the identity service provider, for the relying party's identity authentication: a) < client_id> the identifier of the relying party; b) < client_secret> The password of the relying party. 6.2.4 Requirements for relying party authentication (see 8.1.2), including the following claimed information: the issuer identifier, the subject identifier, the authentication validity period, etc. Three types of authentication: - Authorization code authentication process. It is suitable for relying parties that have the ability to maintain the confidentiality of their credentials, for example, relying parties with a back-end Web server. Such relying parties can use this process to authenticate end users. When interacting with the token endpoint, the identity service provider can authenticate the relying party. All tokens are returned from the token endpoint of the identity service provider; the tokens are not leaked to the user agent. After the relying party obtains the access token and the refresh token, it can proceed to the subsequent access token refresh process. - Implicit identification process. It is suitable for relying parties that are unable to maintain the confidentiality of their credentials, such as JS code or local applications running on a browser. Such relying parties can use this process to authenticate end users. The relying party does not interact with the token endpoint, nor does it perform the identity authentication of the relying party; it cannot perform the subsequent token refresh process. All tokens are returned from the authorization endpoint of the identity service provider. - Hybrid identification process. It combines the first two authentication processes. This process is suitable for such relying parties: the relying party application can obtain the identity of the end user by immediately using the ID token, meanwhile (such as its background service program) can use the authorization code to request a refresh token to obtain longer-term access rights. When interacting with the token endpoint, the identity service provider can authenticate the relying party. When using this process, part of the token is returned from the authorization endpoint of the identity service provider; part of the token is returned from the token endpoint. After the relying party obtains the refresh token, it can proceed to the subsequent access token refresh process. 7.2 Authorization code authentication process 7.2.1 Overview This section describes how to use the authorization code-based authentication process to authenticate the end user. The authorization code authentication process is suitable for relying parties that can securely store the relying party's key. The relying party's key is used to 7.2.3.1 Authentication request The authentication request is constructed by the relying party and used to request the authorization server to authenticate the end user. The authorization server performs the identity authentication of the end user through the authorization endpoint. The authorization endpoint shall support the GET method and POST method using HTTP. The relying party can use HTTP's GET or POST method to send the authorization request to the authorization server. This standard defines the following request parameters for constructing authentication requests: a) < scope>[Mandatory] The scope of the requested resource, the scope parameter of the authentication request shall contain the parameter value openid. If the < scope> parameter does not contain the parameter value openid, it means that the request is not a protocol request as defined by this standard, then this standard does not define the operation of this request. The parameter < scope> may also contain other parameter values. The value of the < scope> parameter that is not understood shall be ignored. See 9.4.1 for the range value. b) < response_type>[Mandatory] Response type value. Set the value of this parameter to code, which means the authorization code authentication process is used. c) < client_id>[Mandatory] The identifier of the relying party, which is used by the authorization server to identify the relying party. d) < redirect_uri>[Mandatory] The URI used by the relying party to receive the response message from the identity service provider. The identity service provider sends the response to the redirected URI. The URI shall exactly match the redirected URI as pre-registered by the relying party in the identity service provider. The matching method shall be the matching method defined in the uniform resource identifier (see RFC 3986) (such as string comparison). Generally, the redirected URI shall be sent using HTTPS. If the HTTP protocol is to be used, the relying party type shall be a relying party with confidentiality capabilities, meanwhile the identity service provider allows the use of redirected URI of the HTTP protocol. e) < state>[Recommended] The authorization server can also try to detect the current user agent and select the appropriate display mode. i) < prompt>[Optional] ASCII string value, which specifies whether the authorization server prompts the terminal user to re-authenticate and apply for authorization, separated by spaces and case sensitive. The parameter values of this parameter are as follows: 1) none: This parameter value means that the authorization server does not display the user interface for identity authentication and authorization application. When the value of < prompt> is none, an error message will be returned (see 7.2.3.6) if the following conditions occur: the end user has not been authenticated, the relying party has not set the parameter value during the registration phase, or other conditions are not met. 2) login: The value of this parameter indicates that the authorization server shall prompt the terminal user to perform identity authentication again. If the end user cannot be re-authenticated, an error message shall be returned, usually login_required. 3) consent: This parameter value indicates that the authorization server shall prompt the end user whether to agree before returning information to the relying party. If consent cannot be obtained, an error message shall be returned, usually consent_required. 4) select_account: This parameter value indicates that the authorization server shall prompt the end user to choose a user account. This parameter is usually used to prompt end users who have multiple accounts to select one from multiple accounts in the current session. If one of the accounts of the end user cannot be obtained, an error message shall be returned, usually account_selection_required. The relying party uses the prompt parameter to ensure that the end user is still in the current session and paying attention to the request. If this parameter contains both the none-value and other values, an error message will be returned. j) < max_age>[Optional] Maximum identification validity period. Refers to the maximum authentication valid time (seconds) since the last terminal user authentication. If the elapsed time is greater than this value, the identity service provider shall re-authenticate the terminal user. When using max_age, the ID token shall include the auth_time parameter (the time to Other parameters may be sent in the authentication request, see authorization request parameters and parameter values as defined in 7.3.3, 7.4.3, 9.2, 9.4. In addition, when implementing the protocol, the protocol request and response parameters as defined in this standard can be passed in the following two ways: - Value transfer: The parameters and parameter values in the protocol request or response are directly attached to the protocol message for transfer; - Reference transfer: The parameters and parameter values in the protocol request or response are passed through the URI reference of the HTTP mechanism. The parameter value is not directly included in the protocol request message, but a reference is included in the request message, that is, a URI, the URI points to a resource object, which contains the requested parameters and parameter values. The specific implementation methods and requirements are not within the scope of this standard. 7.2.3.2 Authentication request validation After receiving the request, the authorization server shall perform the following validation: a) The authorization server shall verify the validity of the authentication request, to ensure that all required parameters are present and valid; b) Verify whether the < scope> parameter is included and whether the scope parameter value contains openid. If the openid value is not included, it indicates that it is not a request as specified in this protocol; c) The authorization server shall follow this standard and verify the validity of all necessary parameters; d) If the ID token request has a sub claim (see 8.1.2), the authorization server can only respond to this request when the end user specified by the sub value has an active session with the authorization server, or the authorization server has authenticated the end user. For other end users, the authorization server cannot return ID tokens or access tokens. This type of request can also be implemented using the id_token_hint parameter or by requesting a specific claim value (implementation shall support the claims parameter) (see 9.4.2). When the authorization server finds an unrecognized request parameter, it shall issue license/authorization information. 7.2.3.5 Authentication success response After the end user successfully passes the identity authentication, the authorization endpoint of the identity service provider shall use the "authentication success response" message as defined in this clause to respond to the authentication request message sent by the relying party. When using the authorization code authentication process, the authorization server shall send the authorization code to the relying party, usually through redirection. The authorization server adds the following parameters to the query component of the redirection endpoint URI (first use UTF-8 to encode the parameters; then use the "application/x-www-form-urlencoded" [RFC1867] format for encoding): a) < code>[Mandatory] The authorization code generated by the authorization server. In order to reduce the risk of leakage, the authorization code shall become invalid within a short time after issuance. It is recommended that the longest life cycle of the authorization code is 10 minutes. The relying party may not reuse the authorization code. The authorization server shall bind the authorization code with the identifier of the relying party and the redirected URI. In the subsequent process of exchanging the authorization code for the access token, if the authorization code is reused, the authorization server shall reject the request and revoke all access tokens previously issued based on the authorization code. b) < state> If this parameter is included in the authentication request of the relying party, this parameter shall also be included in the authentication response. The value of this parameter is the same as the value of < state> in the authentication request sent by the relying party. Relying parties shall ignore unrecognized response parameters. This standard does not define the string length of the authorization code. Relying parties should not make assumptions about string length. The identity service provider shall specify the length of all parameter values issued by it in its service documentation. The issuance of the authorization code shall be transmitted using the secure communication protocol as defined in GM/T 0024-2014. 7.2.3.6 Identification error response If this parameter is included in the authentication request of the relying party, this parameter shall also be included in the response. The value of this parameter is the same as the value of < state> in the relying party authentication request. Relying parties shall ignore unrecognized response parameters. The identity service provider shall specify the length of all p...... ......
 
Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.