Skip to product information
1 of 12

PayPal, credit cards. Download editable-PDF and invoice in 1 second!

GM/T 0069-2019 English PDF (GMT0069-2019)

GM/T 0069-2019 English PDF (GMT0069-2019)

Regular price $685.00 USD
Regular price Sale price $685.00 USD
Sale Sold out
Shipping calculated at checkout.
Quotation: In 1-minute, 24-hr self-service. Click here GM/T 0069-2019 to get it for Purchase Approval, Bank TT...

GM/T 0069-2019: Open identity authentication framework

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.
GM/T 0069-2019
GM
CRYPTOGRAPHIC INDUSTRY STANDARD
OF THE PEOPLE 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, meanwhi...

View full details