OpenID Connect Core 1.0 (V) authentication with authorization code stream (bottom)

3.1.2.6 Validation Error response (authentication error Response)

The validation error response is an OAuth 2.0 authorization error response message, which is the message that the RP sends an authorization request and is returned by the response of the OP authorization endpoint.

If the end user rejects this request or the end user fails to authenticate, the OP (authorization server) notifies the RP (client) by using an error response, whose parameters are defined in the OAuth 2.0 [RFC6749] 4.1.2.1 section. With RFC 6749 (HTTP error is returned to the user agent using the appropriate HTTP status code. )

Unless the redirected URI is invalid, the authorization server returns the authorization request specified in the URI that is redirected by the client with the appropriate error and status parameters. Other parameters should not be returned.

In addition to the error code defined by the OAuth 2.0 4.1.2.1 section, the specification also defines the following error code:

Interaction_required

The authorization server requires some form of interaction with the end user. When the prompt parameter value of none is included in the authentication request, this error may be returned, but the validation request cannot be completed without the user interface showing the end user action to lose weight.

Login_required

The authorization server requires the end user to authenticate. When the prompt parameter value of none is included in the authentication request, this error may be returned, but the validation request cannot be completed without the user interface showing the end user action to lose weight.

Account_selection_required

is required for end users when a session is selected on the authorization server. When the end user does not select the session, but the end user may also be in the authorization authentication server with the different account shut down. When the prompt parameter value of none is included in the authentication request, this error may be returned, but the validation request cannot be completed without the user interface showing the end user action to lose weight.

Consent_required

The authorization server requires end-user consent. When the prompt parameter value of none is included in the authentication request, this error may be returned, but the validation request cannot be completed without the user interface showing the end user action to lose weight.

Invalid_request_uri

The authorization request returns a Request_uri that contains an error or contains invalid data.

Invalid_request_object

The request parameter contains an invalid requested object.

request_not_supported

OP does not support the use of the request parameter defined in section sixth.

request_uri_not_supported

OP does not support the use of the Request_uri parameter defined in section sixth.

registration_not_supported

OP does not support the use of the registration parameter defined in Section 7.2.1.

The error response parameters are as follows:

Error

Required. The error code.

Error_description

Optional. Human-readable ASCII-encoded text describes the error.

Error_uri

Optional. Contains additional information about the URI of the Web page error.

State

OAuth 2.0 status value. If necessary, include the state parameter authorization request. Sets the value received from the client.

When using the authorization code stream, add the error response parameters to the URI of the redirected query component, unless you specify a different response pattern.

The following is a non-canonical example of using the error response (line break only shows the display purpose):

http/1.1 302 Found

LOCATION:HTTPS://CLIENT.EXAMPLE.ORG/CB?

Error=invalid_request

&error_description=

Unsupported%20response_type%20value

&state=af0ifjsldkj

3.1.2.7 Validation Response Verification (authentication Response Validation)

When using the authorization code stream, the client must verify the response according to RFC 6749, especially 4.1.2 and section 10.12.

3.1.3 Token end point (token Endpoint)

Get access Token,id token, and optionally refresh TOKEN,RP (client) to send a token request to the token endpoint and obtain a token response. Use the authorization code stream, as described in section 3.2, OAuth 2.0 (RFC6749).

TLS must be used with the token communication endpoint. See section 16.17 for more information on using TLS.

Request for 3.1.3.1 tokens (token request)

The client issues a token request, presents its license (in the form of an authorization code), and provides a grant_type value for the token endpoint, just as Authorization_code described in the OAuth 2.0 [RFC6749] 4.1.3 section. If the client is a confidential client, it must use a validation method to validate the client_id value of the token endpoint registration, as described in section 9.

The client sends the token endpoint using the HTTP POST method and form serialization parameters, as described in the OAuth 2.0 [RFC6749] 13.2, 4.1.3 section.

The following is a request for a non-canonical token:

Post/token http/1.1

Host:server.example.com

content-type:application/x-www-form-urlencoded

Authorization:basic CZZCAGRSA3F0MZPNWDFMQMF0M2JW

Grant_type=authorization_code&code=splxlobezqqybys6wxsbia

&redirect_uri=https%3a%2f%2fclient.example.org%2fcb

3.1.3.2 Request token authentication (token request Validation)

The authorization server must verify that the token request is as follows:

1. Authenticate the client, if it is to publish client credentials or use another Client authentication method, section 9th defines;
2. Ensure that the authorization code is published to the authenticated client.
3. Verify that the authorization code is valid.
4. If possible, the authentication authorization code is not used before.
5. Make sure that the Redirect_uri parameter value is the same as the Redirect_uri parameter value of the original authorization request. If the Redirect_uri parameter value is a nonexistent Redirect_uri registered value, the authorization server may return an error (because the client should include this parameter) or it may not return an error (because OAuth 2.0 allows parameters to be omitted in this case).
6. Verify that the authenticator used and the OpenID Connect authentication request issuer (so ID token will be returned from the token endpoint).

3.1.3.3 Successful token response (successful token Response)

From the client receiving and validating a valid and authorized token request, the authorization server returns a successful response that contains an ID token and an access token. A successful response is defined in the OAuth 2.0 [RFC6749] 4.1.4 section parameter. The response uses the Application/json meta data type.

When using OAuth 2.0 (RFC6750) to specify a bearer token, the OAuth 2.0 token_type response parameter value must be bearer, unless it is another token type that has been negotiated with the customer. The server should support the bearer token type; Use other types of tokens beyond the scope of this specification.

In addition to the response parameters for the specified OAuth 2.0, the following parameters must be included in the response:

Id_token

ID Token value associated with the authentication session .

All token responses, keys, or other sensitive information that contains tokens must include the following HTTP response header fields and values:

Header Name	Header Value
Cache-control	No-store
Pragma	No-cache

The following is a non-canonical example of a successful token response:

http/1.1 OK

Content-type:application/json

Cache-control:no-store

Pragma:no-cache

{

"Access_token": "slav32hkkg",

"Token_type": "Bearer",

"Refresh_token": "8xloxbtzp8",

"Expires_in": 3600,

"Id_token": "Eyjhbgcioijsuzi1niisimtpzci6ijflowdkazcifq.ewogimlzc     Yi6icjodhrwoi8vc2vydmvylmv4yw1wbguuy29tiiwkicjzdwiioiaimjq4mjg5     Nzyxmdaxiiwkicjhdwqioiaiczzcagrsa3f0myisciaibm9uy2uioiaibi0wuzz Fv3pbmk1qiiwkicjlehaioiaxmzexmjgxotcwlaogimlhdci6idezmteyoda5nz Akfq.ggw8hz1euvluxnuuijkx_v8a_     Omxzr0ehr9r6jgdqroof4dagu96sr_p6q JP6ICMD3HP99OBI1PRS-CWH3LO-P146WAJ8IHEHCWL7F09JDIJMBQKVPEB2T9CJ NQEGPE-GCCMG4VFKJKM8FCGVNZZUN4_KSP0AAP1TOJ1ZZWGJXQGBYKHIOTX7TPD qyhe5lcmikpxfeiqilvq0pc_e2dzl7emopwoaoztf_m0_     N0yzfc6g6ejboeoros K5HODALRCVRYLSRQAZZKFLYUVCYIXEOV9GFNQC3_OSJZW2PAITHFUBEEBLUVVK4 XUVRWOLRLL0NX7RKKU8NXNHQ-RVKMZQG "

}

In OAuth 2.0 (RFC6749), the customer should ignore the non-recognized parameters to respond.

3.1.3.4 Token Error response (token error Response)

The authorization server constructs an error response if the token request is invalid or unauthorized. The parameters of the token's error response are defined in the OAuth 2.0 [RFC6749] 5.2 section. The body of the HTTP response uses the HTTP 400 response of the Application/json media type.

The following is an example of a non-canonical token error response:

http/1.1 Bad Request

Content-type:application/json

Cache-control:no-store

Pragma:no-cache

{

"Error": "Invalid_request"

}

3.1.3.5 Token response Acknowledgement (token Response Validation)

The client must verify that the token response is as follows:

1, follow the verification rules of RFC 6749, especially in the sections 5.1 and 10.12.

2. Verify ID Token According to 3.1.3.7 validation rules.

3. Verify access Tokens in accordance with 3.1.3.8 validation rules.

3.1.3.6 ID Token

The contents of the ID token are described in the second section. When using the authorization code stream, the following claims Request ID token for additional requirements:

At_hash

Optional. The hash value of Access token. Its value is the leftmost base64url encoded half of the hash of the eight-byte ASCII representation of the Access_token value, and the hash algorithm used is used in the ALG header parameter's ID token of the Jose header. For example, if ALG is RS256, use the Access_token value of the SHA-256 hash, and then encode the leftmost 128-bit base64url. The At_hash value is a case-sensitive string.

3.1.3.7 ID token verification (ID token Validation)

The customer must verify the ID token in the token response using the following methods:

1, if the ID token is encrypted, use the cryptographic ID token used by the client during the registration by OP to decrypt the key and algorithm. If the encryption and ID token are not encrypted while registering the OP, the RP should reject it.

2. The issuance of the OpenID provider identifier (which is usually obtained upon discovery) must match the ISS (issuer) statement exactly.

3. The client must verify that an AUD (consumer) statement containing the CLIENT_ID value is included in the registered ISS (issuer) statement identified by the issuer as a consumer. The AUD (consumer) claim may contain more than one array element. If the ID token list does not have the client as a valid consumer, or if it contains additional, client untrusted consumers, this ID token must be rejected.

4. If the ID token contains multiple consumers, the client should verify that the AZP (licensor) statement exists.

5. If the AZP (licensor) statement exists, the customer should confirm that it client_id is a claim value.

6. If the ID of the communication (internal process) between the client and the token endpoint is received directly, the TOKEN,TLS verifies that the server can be used in place of the Publisher validation check token signature. The client must verify all other ID token signatures, using JWS to specify the cryptographic algorithm containing the JWT ALG header parameter. The client must be decrypted using the keys provided by the issuer.

7. The value of the ALG should be the default RS256 or the algorithm that the client sends through the ID_TOKEN_SIGNED_RESPONSE_ALG parameter during the registration process.

8. If the JWT ALG header parameter uses a MAC-based algorithm such as HS256, HS384, or HS512, the UTF-8 eight-byte representation of the Client_secret corresponds to the client_id that contains the AUD (consumer) Declaration as key to verify the signature. Based on the MAC algorithm, its behavior is unspecified if the AUD has multiple values or if the AZP value has a different AUD value.

9. The current time must precede the time represented by the exp (validity) declaration.

10. When the issue exceeds the valid time period, the IAT declaration can reject the use of tokens, and the limit number of nonces must be stored to block the attack. The acceptable range is specific to the customer.

11. If the Nonce value sends a validation request, a nonce declaration must exist and use its value to verify that the check is the same value as the nonce sent as a validation request. The client should check the Nonce value to prevent replay attacks. This is an effective way to prevent replay attacks on specific customers.

12. If there is an ACR claim request, the client should check the assertion claim value is appropriate. The significance of processing ACR claim values is beyond the scope of this specification.

13. If a auth_time declaration is required, either through a specific request declaration or by using the Max_age parameter, the client should check the value of the Auth_time declaration and, when the last authenticated end user has been authenticated for too long, must request a reauthentication.

3.1.3.8 access token verification (access token Validation)

When using the authorization code stream, if the ID token contains a At_hash declaration, the client can use it to verify the implicit process access token that is defined in the 3.2.2.9 in the same way, but returns the ID token and access token from the token endpoint.

OpenID Connect Core 1.0 (V) authentication with authorization code stream (bottom)