GM/T 0068-2019 English PDF (GMT0068-2019)

Delivery: 3 seconds. Download true-PDF + Invoice.
Get QUOTATION in 1-minute: Click GM/T 0068-2019
Historical versions: GM/T 0068-2019
Preview True-PDF (Reload/Scroll if blank)

GM/T 0068-2019: Open third party resource authorization protocol framework
GM/T 0068-2019
GM
CRYPTOGRAPHY INDUSTRY STANDARD
OF THE PEOPLE’S REPUBLIC OF CHINA
ICS 35.0404
L 80
Open Third-Party Resource Authorization Protocol
Frame
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 ... 8
5 Overview ... 9
5.1 Protocol process ... 9
5.2 Protocol channel requirements ... 10
5.3 Protocol endpoint ... 11
6 Third-Party Applications and Security Requirements ... 14
6.1 Types of third-party applications ... 14
6.2 Third-party application identifier ... 16
6.3 Registration requirements for the third-party applications ... 16
6.4 Identity authentication of the third-party application ... 16
7 Authorization Process ... 19
7.1 Authorization grant ... 19
7.2 Authorization code grant process ... 20
7.3 Implicit grant process ... 27
7.4 Resource owner password credential grant process ... 32
7.5 Third-party application identity credential grant process ... 34
8 Token ... 36
8.1 Token type ... 36
8.2 Issuance of access tokens ... 39
8.3 Access token refresh ... 41
9 Access to Protected Resources ... 42
9.1 Access process of protected resources... 42
9.2 Successful response ... 43
9.3 Error response ... 43
Appendix A (Informative) Description of Protocol Parameters ... 44
Bibliography ... 46
Open Third-Party Resource Authorization Protocol
Frame
1 Scope
This Standard specifies the process of third-party resource authorization protocol,
different types of authorization licenses, the functional requirements of each endpoint
of the protocol, and the format and parameter requirements of messages transmitted
between system entities.
This Standard is applicable to the development, testing, evaluation and procurement
of identity authentication and authorization services in the Internet cross-security
domain application scenario.
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 document.
GB/T 15843.3-2008 Information Technology - Security Techniques - Entity
Authentication - Part 3: Mechanisms Using Digital Signature Techniques
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 Information Security Technology - Public Key Cryptographic
Algorithm SM2 Based on Elliptic Curves - Part 2: Digital Signature Algorithm
GB/T 32918.4-2016 Information Security Technology - Public Key Cryptographic
Algorithm SM2 Based on Elliptic Curves – Part 4: Public Key Encryption Algorithm
GM/T 0024-2014 SSL VPN Specification
RFC 1867 Form-Based File Upload in HTML
RFC 2616 Hypertext Transfer Protocol – HTTP/1.1
RFC 2617 HTTP Authentication: Basic and Digest Access Authentication
party application uses the authorization server as an intermediary to obtain the
authorization grant from the resource owner, as shown in Figures 2 and 3;
b) The resource owner [or the resource owner indirectly through the authorization
server, as described in step a)] issues authorization grant to the third-party
application. This authorization grant is a credential authorized by the resource
owner, and the used type is one of the four types defined in 7.1.1. The type of
authorization grant depends on the way the third-party application requests
authorization [that is, the two ways described in step a)] and the type of
authorization grant supported by the authorization server (usually provided by
the service document of the authorization server);
c) The third-party application authenticates the authorization server and submits the
authorization grant, requesting an access token from the authorization server;
d) The authorization server authenticates the identity of the third-party application
and verifies the validity of the authorization grant. If the identity of the third-party
application is successfully authenticated and the authorization grant is valid, the
authorization server issues an access token to the third-party application;
e) Third-party applications send access tokens and related parameters to the
resource server to request access to protected resources;
f) The resource server verifies the validity of the access token. If the access token
is valid, the requested resource is returned to the third-party application.
Based on the above protocol process, third-party application may interact with the
resource owner through the user agent (such as a browser) used by the resource
owner. In some specific situations (see 7.5), the third-party application may not interact
with the resource owner. Interactively, directly use the identity credentials of the third-
party application to obtain the access token issued by the authorization server. If the
third-party application's access to the protected resource exceeds the scope or validity
period of the access token, the access becomes invalid; and the third-party application
should restart the protocol process or use the refresh mechanism specified in this
Standard to update the access token.
This Standard uses the hypertext transfer protocol HTTP1.1 (see RFC 2616) for
communication. The open third-party resource authorization protocol framework based
on any other protocol does not belong to the scope of this Standard.
5.2 Protocol channel requirements
For sensitive data such as authorization codes, access tokens, refresh tokens,
resource owner password credentials, and third-party application identity credentials,
plaintext transmission shall not be used; and the secure transport layer protocol
defined by GM/T 0024-2014 shall be used for transmission. The authorization server
If the third-party application has registered multiple redirection endpoint URIs, or only
registered a part of the redirection endpoint URI, or has not registered the redirection
endpoint URI, the third-party application shall use < redirect_uri> parameter in the
request when sending authorization requests to identify the redirection endpoint URI
used in this request.
When the authorization request contains the redirection endpoint URI, if the third-party
application has registered the redirection endpoint URI, the authorization server shall
use the comparison and matching method defined in section 6 of RFC 3986 to
compare and match the received redirection endpoint URI and the previous registered
redirection endpoint URI. If the third-party application registers the complete URI, the
authorization server shall use the simple string comparison method defined in section
6.2.1 of RFC 3986 to compare the two redirection endpoint URIs.
If the authorization request fails verification because the redirection endpoint URI is
missing, invalid, or mismatched, the authorization server shall inform the resource
owner of the error, and shall not automatically redirect the user agent to the redirection
endpoint URI that fails the verification.
The redirection request sent to the redirection endpoint of the third-party application
usually gets the response of the HTML document, and the response is processed by ...