Overview#

Authentication Request in OpenID Connect is an Authorization Request that requests that the Resource Owner be authenticated by the Authorization Server.

The Authentication Request is specifically identified from an OAuth 2.0 Authorization Request by the presence present only when the "OpenID" OAuth Scope value is present.

OAuth 2.0 Authentication Request using extension parameters and scopes defined by OpenID Connect to request that the Human participant be authenticated by the Authorization Server, which is an OpenID Connect Provider, to the OAuth Client, which is an OpenID Connect Relying Party.

Authorization Servers MUST support the use of the HTTP GET and HTTP POST methods defined in at the Authorization_endpoint. OAuth Clients MAY use the HTTP GET or HTTP POST methods to send the Authentication Request to the Authorization Server. If using the HTTP GET method, the request parameters are serialized using URI Query String Serialization. If using the HTTP POST method, the request parameters are serialized using Form Serialization.

Authentication Request Validation#

The Authorization Server MUST validate the Authentication Request received as follows:

• The Authorization Server MUST validate all the OAuth 2.0 parameters according to the OAuth 2.0 specification.
• Verify that a scope parameter is present and contains the openid scope value. (If no openid scope value is present, the request may still be a valid OAuth 2.0 Authorization Request, but is not an OpenID Connect Authentication Request.)
• The Authorization Server MUST verify that all the REQUIRED parameters are present and their usage conforms to OpenID Connect Core 1.0 specification.
• If the sub (subject) Claim is requested with a specific value for the id_token, the Authorization Server MUST only send a positive response if the End-User identified by that sub value has an active session with the Authorization Server or has been Authenticated as a result of the request. The Authorization Server MUST NOT reply with an id_token or Access_token for a different user, even if they have an active session with the Authorization Server. Such a request can be made either using an id_token_hint parameter or by requesting a specific Claim Value as described in OpenID Connect Core 1.0 Section 5.5.1, if the claims parameter is supported by the implementation.

As specified in OAuth 2.0 RFC 6749, Authorization Servers SHOULD ignore unrecognized Authentication Request parameters.

If the Authorization Server encounters any error, it MUST return an error response, OpenID Connect Core 1.0 per Section 3.1.2.6.

If no errors are encountered, then the following proceeds:

• Authorization Server Authenticates End-User
• Authorization Server Obtains End-User Consent/Authorization
• OpenID Connect Authentication Response

More Information#

There might be more information for this subject on one of the following:

• AUTHENTICATE_SESSION
• Account_selection_required
• Acr_values
• Amr_values
• Authentication Context Class
• Authentication Context Class Reference
• Authentication Context Class vs Authentication Method Reference
• Authentication Method
• Authentication Method Reference
• Authentication Request
• Authorization Code
• Authorization Code Flow
• Authorization Request Parameters
• Authorization Server Authentication of the End-User
• Best Practices OpenID Connect
• Binding_message
• Consent_required
• Credential Management API
• DSE_LOGIN_EX
• Google OpenID Connect
• Hosted domain
• Hybrid Flow
• Identity Token
• Identity Token Validation
• Interaction_required
• Invalid_request_object
• Login_hint
• Login_hint_token
• Login_required
• Max_age
• OAuth 2.0 Device Authorization Grant
• OAuth 2.0 Protocol Flows
• OAuth Parameters Registry
• OAuth Scopes
• OpenID Connect Authentication Response
• OpenID Connect Authorization Flow
• OpenID Connect Claims
• OpenID Connect MODRNA Authentication Profile 1.0
• Openid scope
• Prompt Parameter
• Refresh Token
• Security Reference Monitor
• Userinfo_endpoint