Powered by Google www.ChineseStandard.net Database: 189760 (20 Apr 2024)

GM/T 0069-2019 (GMT0069-2019)

GM/T 0069-2019_English: PDF (GMT 0069-2019, GMT0069-2019)
Standard IDContents [version]USDSTEP2[PDF] delivered inStandard Title (Description)StatusPDF
GM/T 0069-2019English690 Add to Cart 0--9 seconds. Auto-delivery Open identity authentication framework Valid GM/T 0069-2019

BASIC DATA
Standard ID GM/T 0069-2019 (GM/T0069-2019)
Description (Translated English) Open identity authentication framework
Sector / Industry Chinese Industry Standard (Recommended)
Classification of Chinese Standard L80
Classification of International Standard 35.040
Word Count Estimation 46,488
Date of Issue 2019
Date of Implementation 2019-07-12

Standards related to: GM/T 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 parameter values
issued by it in its service documentation.
7.2.4.4 Token error response
If the token request is invalid or unauthorized, the authorization server shall
return an error response. The HTTP response body uses the type defined in
application/json (see RFC 4627). The authorization server returns an HTTP
response with a status code of 400 (Bad Request) and includes the following
parameters in the response:
a) < error>[Mandatory]
Error codes in ASCII format have the following types:
1) invalid_request means that the request is missing a mandatory
parameter, or contains a parameter value that is not supported (but if
the license is an unsupported type, the returned error code shall be
invalid_grant), or it contains a parameter repeatedly, or contain multiple
credentials, or use multiple relying party identity authentication
methods.
2) invalid_client indicates that the authentication of the relying party failed.
The authorization server can return an HTTP response with a status
code of 401, to indicate which HTTP authentication schemes are
supported.
3) invalid_grant indicates that the authorization permission provided by
the relying party (for example, authorization code, resource owner’s
password credentials) or refresh token is invalid, or expired, or revoked,
or failed to match the redirection endpoint URI provided in the
authorization request, or is issued to another relying party.
4) unauthorized_client means that the authorization server does not allow
the relying party to use the current authorization type.
5) The unsupported_grant_type means that authorization server does not
support the currently used authorization type.
6) invalid_scope means that the scope of the requested access to the
protected resource is invalid, unknown, incorrectly formatted, or beyond
The relying party shall verify the ID token in the token response in the following
ways:
a) If the ID token is encrypted, use the key and algorithm set during the
registration process of the relying party to decrypt the ID token. The key
agreement between the relying party and the identity service provider can
be implemented during the relying party registration process; the specific
implementation process is outside the scope of this standard. If the relying
party negotiates with the identity service provider to use an encrypted ID
token, but the ID token is not encrypted, then the relying party shall reject
the token.
b) The issuer identifier of the identity service provider (see 6.1.3) shall exactly
match the < iss> parameter.
c) The relying party shall verify the client_id value in the ID token aud claim,
which is registered with the issuer specified in the iss claim. The aud claim
may contain an array, which contains multiple relying party identifiers. If
the ID token does not list the relying party as a valid receiver, or it contains
a receiver that is not trusted by the relying party, the ID token shall be
rejected.
d) If the I...
...