Authorization Code Flow:

The Authorization Code Flow goes through the following steps.

  • Client prepares an Authentication Request containing the desired request parameters.

  • Client sends the request to the Authorization Server.

  • Authorization Server Authenticates the End-User.

  • Authorization Server obtains End-User Consent/Authorization.

  • Authorization Server sends the End-User back to the Client with an Authorization Code.

  • Client requests a response using the Authorization Code at the Token Endpoint.

  • Client receives a response that contains an ID Token and Access Token in the response body.

  • Client validates the ID token and retrieves the End-User's Subject Identifier.

Authentication Request:
HTTP/1.1 302 Found

OpenID Connect uses the following OAuth 2.0 request parameters with the Authorization Code Flow:

scope REQUIRED. OpenID Connect requests MUST contain the openid scope value. If the openid scope value is not present, the behavior is entirely unspecified. Other scope values MAY be present. Scope values used that are not understood by an implementation SHOULD be ignored.

response_type REQUIRED. OAuth 2.0 Response Type value that determines the authorization processing flow to be used, including what parameters are returned from the endpoints used. When using the Authorization Code Flow, this value is code.

client_id REQUIRED. OAuth 2.0 Client Identifier valid at the Authorization Server.

redirect_uri REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider. When using this flow, the Redirection URI SHOULD use the https scheme; however, it MAY use the http scheme, provided that the Client Type is confidential, OAuth 2.0, and provided the OP allows the use ofhttp Redirection URIs in this case. The Redirection URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application.

state RECOMMENDED. Opaque value used to maintain state between the request and the callback. Typically, Cross-Site Request Forgery (CSRF, XSRF) mitigation is done by cryptographically binding the value of this parameter with a browser cookie.

Authentication Request Validation
  • 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 request but is not an OpenID Connect request.)

Authentication Response:
Token Request:
POST token-srv/token HTTP/1.1
  Content-Type: application/x-www-form-urlencoded
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

Token Response:

HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store Pragma: no-cache

   "access_token": "eyJhbGciOiJS....",
   "token_type": "Bearer",
   "refresh_token": "8xLOxBtZp8....",
   "expires_in": 3600,
   "id_token": "eyJhbGciOiJSUzI1N......"

results matching ""

    No results matching ""