OpenID Connect Core 1.0 (iv) Authentication with authorization code flow (UP)

3.1 Using Authorization Code flow verification (authentication using the Authorization code flow)

This section describes how to perform validation using authorization code flow. When the authorization code stream is used, all tokens are returned from the token endpoint.

The authorization code stream returns the authorization code to the client, which can exchange an ID token and an access token directly. This gives the user agent the benefit of not exposing any tokens, as there may be other malicious applications accessing the user agent. The authorization server can also exchange authorization codes through access token before authenticating the client. Authorization streams are suitable for scenarios where customer password maintenance can be securely maintained between the customer and the key authorization server.

3.1.1 Authorization Stream Step (Authorization code flow Steps)

The authorization code stream follows these steps.

1. The customer prepares a request parameter that contains the required validation request.

2, the client sends the request to the authorization server.

3, the authorization server authenticates the user.

4. The authorization server obtains the user consent/authorization.

5, the authorized server to the end user to send back an authorization code to the client.

6. The client uses the authorization code to request a response from the token endpoint.

7, the client receives a token with an ID and access token response body.

8, the client verifies the ID token and retrieves the end user's subject identifier.

3.1.2 Authorization Endpoint (Authorization Endpoint)

Authentication of the end user by the authorization endpoint. is a validation and authorization endpoint that sends the user agent to the authorization server whose request parameters are defined in OAuth 2.0, and the additional parameters and parameter value definitions are defined in OpenID connect.

The communication for the authorization endpoint must use TLS. See section 16.17 For more information about TLS.

3.1.2.1 Authentication requests (authentication request)

An authentication request is an authorization request that OAuth 2.0 authenticates to the end user of the authorization server.

The authorization server must support the HTTP GET and Post methods defined in RFC 2616 using the authorization endpoint. Customers can use the HTTP GET or POST method to send authorization requests to the authorization server. If you use the HTTP GET method, the serialization of the request parameter is serialized using a per-URI query string (section 13.1). If you use the HTTP POST method, request parameter serialization using Form serialization form (Section 13.2).

OpenID Connect uses the following request parameters for the OAuth 2.0 authorization stream:

Scope

Required. The OpenID connect request must contain the OpenID scope value. If the OpenID scope value does not exist, its behavior is completely indeterminate. There may be other scope values. It is not possible to understand that the scope implementation value should be ignored. See (5.4 and 11 for the additional scope Value section of this specification definition).

Response_type

Required. Determines the process by which authorization is processed, and what parameters are returned from the endpoint are determined by the OAuth 2.0 response type value. When using the authorization code stream, its value is code.

client_id

Required. OAuth 2.0 is a valid client identifier for the authorization server.

Redirect_uri

Required. The redirect URL that will be sent by the response. This URI must be a redirect URI value that exactly matches the client's pre-registered OpenID provider, and the description of the matching execution is in section 6.2.1 (RFC3986) (simple string comparison). When using this process, the redirect URI should use the HTTPS scheme; However, it can also use the HTTP scheme, where the OP allows the use of HTTP redirection URLs to provide a way to provide client type secrecy, as defined in the OAuth 2.0 2.1 section. A redirected URI might use an alternative, for example, when the purpose is to identify a callback for a native application.

State

Recommended. An opaque value that is used when maintaining the state between the request and the callback. In general, the value is encrypted by a cookie in the browser to reduce cross-site request forgery (CSRF XSRF).

OpenID Connect also uses the OAuth 2.0 request parameter, which has multiple response type coding practices in OAuth 2.0.

Response_mode

Optional. Notifies the authorization server of the mechanism used to return parameters from the authorization endpoint. It is not recommended to use this response mode parameter, but to set its request to the default mode specified by the response type.

This specification also defines the following request parameters :

Nonce

Optional. A string value that is used to correlate the ID Token of the client session to mitigate replay attacks. The value is not modified in the authentication ID token request. The nonce must have enough complexity to prevent the attacker from guessing the value. For implementation instructions, see section 15.5.2.

Display

Optional. The ASCII string value of the authentication and authorization server that indicates how to display the value defined on the user interface page that is approved by the end user is:

Page

The authorization server should display a consistent view of the validation and consent UI with a full user Agent page. If no display parameters are specified, the default display mode is used.

Popup

The authorization server should display a pop-up user Agent window that validates and matches the user consent interface. The pop-up user Agent window should be the appropriate size, and the entire window should not obscure the Login-focused dialog box rendering.

Touch

The authorization server should use the authentication and consistent user consent interface that is displayed in the touch device.

Wap

The authorization server should display the authentication and the consistent user consent interface in "feature phone".

The authorization server may also attempt to detect the user agent functionality and render an appropriate display.

Prompt

Optional. A space-delimited, case-sensitive list of ASCII string values that specifies whether the authorization server prompts the end user for reauthentication and consent. The values defined are:

None

The authorization server cannot display any authenticated or consented user pages. An error is returned if an end user has not yet been authenticated or the client does not have a preconfigured request to consent to the claim or to satisfy other conditions to process the request. The usual error code is login_required, interaction_required, or another code defined in section 3.1.2.6. A method that can be used to check for existing authorizations and/or consents.

Login

The authorization server should prompt the end user to re-authenticate. If the end user cannot re-authenticate, an error must be returned, usually login_required.

Consent

The authorization server should prompt the end user for permission and then return information to the client. If it cannot get permission, it must return an error, usually consent_required.

Select_account

The authorization server should prompt the user to select an account. This makes multiple account selections in the current session on an authorized server with multiple accounts for an end user. If you cannot get an account selected by the end user, you must return an error, usually account_selection_required.

The prompt parameter can be used by the client to ensure that the end user exists or requests intent in the current session. If this parameter does not contain any other values, an error is returned.

Max_age

Optional. Verify the maximum expiration time. Specifies the allowable duration in seconds, which is the duration of the validation since the last time the OP end user was activated, and if the duration is greater than this value, the OP must actively attempt to reconfirm the end user. (The max_age request parameter corresponds to the max_auth_age request parameter of the OpenID 2.0 PAPE (openid.pape).) When using Max_age, a Auth_time claim value must be included in the returned ID token.

Ui_locales

Optional. The preferred language and script for the end user interface, represented as a space-delimited list of BCP47 RFC5646 language tag values, sorted by preference. For example, the value "Fr-ca fr en" represents a preference: Canadian French, French (no region specified), followed by English (no region specified). If the OpenID provider does not support partial and all requested locales, the locale should not produce an error.

Id_token_hint

Optional. The ID Token previously issued by the authorization server, as a hint, is passed to the end user to authenticate with the client in the current or past session. If the end user has been logged in with the ID token login confirmation or a signed-in request, then the authorization server returns a positive response; otherwise, it should return an error, such as login_required. When possible, you should use Id_token_hint when Prompt=none, and if not, return a invalid_request error; Of course, the server should respond successfully if allowed, even if it does not exist. The authorization server should not sit idly by when the ID token uses the Id_token_hint value.

If the RP receives an op-encrypted ID token and uses it as a id_token_hint, the client must decrypt the signature ID token that contains the cryptographic ID token. The customer may use the key value that the authentication server can decrypt to re-encrypt the signature ID token, and encrypt the Id_token_hint value with the re-encrypted ID token.

Login_hint

Optional. About the end user may log on using the login identifier (if necessary) to prompt the authorization server. This hint can be used by the RP if it first addresses the end user's e-mail address (or other identifiers) and then wants to pass this value as a Discovery authorization service hint. The recommended hint value matches the value used for discovery. This value may be a phone number in the format of the specified Phone_number declaration. The OP determines whether to use this parameter.

Acr_values

Optional. The validation context class reference value for the request. Specifies the ACR space-delimited string values that are requested by the authorization server to process the authentication request, and the values appear in order of precedence. As the ACR claim value returns the validation context class that satisfies the execution validation, and the second section specifies that the ACR claim request is an actively declared parameter.

Other parameters may be sent. See section 3.2.2, 3.3.2, 5.2, 5.5, 6, 7.2.1, additional authorization request parameters and parameter values defined by the specification.

The following is a non-canonical example of an HTTP 302 redirect response from the client, which validates the request authorization endpoint trigger:

http/1.1 302 Found

Location:https://server.example.com/authorize?

Response_type=code

&scope=openid%20profile%20email

&client_id=s6bhdrkqt3

&state=af0ifjsldkj

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

The following is a request for a denormalized example, which will be sent by the user agent to the authorization server, responding to the HTTP 302 redirect Response client above:

Get/authorize?

Response_type=code

&scope=openid%20profile%20email

&client_id=s6bhdrkqt3

&state=af0ifjsldkj

&REDIRECT_URI=HTTPS%3A%2F%2FCLIENT.EXAMPLE.ORG%2FCB http/1.1

Host:server.example.com

3.1.2.2 Authentication request Verification (authentication request Validation)

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

1. The authorization server must validate all OAuth 2.0 parameters according to the OAuth 2.0 specification.

2. Verify that the scope parameter exists and contains the OpenID scope value. (If there is no OpenID scope value, the request may still be a valid OAuth 2.0 requirement, but not an OpenID connect request.) )

3. The authorization server must verify that all required parameters exist and that their use complies with this specification.

4. If the sub (subject) declares that the ID Token of a specific value is requested, the authorization server will only send a positive response if the end user confirms that the sub value is having a session active with the authorization server or the result of a request that has been authenticated. The licensing server does not have to reply to the ID tokens or access tokens for different users, even if they have active sessions with the authorization server. If you have such a requirement, you can use the Id_token_hint parameter or by requesting a specific claim value that is described in section 5.5.1. If the declaration parameter supports implementation.

OAuth 2.0 (RFC6749) indicates that the authorization server should ignore unrecognized request parameters.

If the authorization server encounters any errors, it must return an incorrect response, see section 3.1.2.6.

3.1.2.3 Authorization Server Authentication User (Authorization server authenticates end-user)

If the request is valid, the authorization server attempts to authenticate the end user or determine end-user authentication, depending on the requested parameter value used. The method used by the authorization server to authenticate the end user (such as user name and password, session cookie, and so on). Beyond the scope of this specification. The authorization server displays the validation user interface based on the request parameter value and the authentication method used.

The authorization server must attempt to authenticate the end user in the following situations:

• The end user is not authenticated.
• The validation request contains the login prompt parameter value. In this case, the authorization server must re-authenticate the end user, even if the end user has passed the authentication.

The authorization server should not interact with the user in the following situations:

• The validation request does not contain any login prompt parameter values. In this case, the authorization server must return an error if an end-user is not already authenticated or cannot implicitly pass the authentication.

When interacting with an end user, the authorization server must take appropriate precautions against cross-site request forgery and "Click Hijacking" as described in the OAuth 2.0 [RFC6749] 10.12 and 10.13 chapters.

3.1.2.4 Authorization Server obtains user consent/authorization (Authorization server obtains end-user consent/authorization)

Once the end user is authenticated, the authorization server must obtain an authorization decision before placing the information on the relying party section. When using the request parameter is licensed, it can be used with the end user through an interactive conversation to make it clear that it has been agreed to or through the establishment of a conditional processing request under the consent of other means (for example: through previous management licenses). In the 2 and 5.3 information release mechanism sections are described.

3.1.2.5 Successful validation response (successful authentication Response)

A validation response is an OAuth 2.0 authorization response message that is issued from an RP authorization request and is responded to by the OP's authorization endpoint.

When using the authorization code stream, the authorization response returns the parameters defined by the OAuth 2.0 (RFC6749) 4.1.2 section, by adding the authorization request specified in the query parameters Redirect_uri, using the application/ x-www-form-urlencoded format, unless you specify a different response mode.

The following is an example of a successful response using this process denormalized:

http/1.1 302 Found

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

Code=splxlobezqqybys6wxsbia

&state=af0ifjsldkj

For the implementation example, refer to the 15.5.1 section for authorization code content.

OpenID Connect Core 1.0 (iv) Authentication with authorization code flow (UP)