Invoking the Authorization Endpoint for OpenID Connect

In OpenID Connect the authorization endpoint handles authentication and authorization of a user.

When starting the authorization endpoint from an in-browser client application or a client application implemented in a scripting language such as Javascript, for example, no configuration of a Liberty profile server as an OpenID Connect Client is necessary.

The authorization endpoint accepts an authentication request that includes parameters defined by both the OAuth 2.0 and OpenID Connect 1.0 specifications.

In the Authorization Code Flow, the authorization endpoint is used for authentication and authorization and returns an authorization grant to the client. This authorization grant can then be passed in a request by the client to the token endpoint in exchange for an ID token, access token, and refresh token. In the Implicit Flow, the authorization endpoint still performs authentication and authorization but also directly returns an ID token and access token to the client in its response; no interaction is performed with the token endpoint.

A Liberty profile server with OpenID Connect enabled has access to the OpenID Connect authorization endpoint at the following URL:

https://server.example.com:443/oidc/endpoint/<provider_name>/authorize

In this example the SSL port of the OP is expected to be 443.

1. Prepare an HTTP GET or POST request that includes the following required and recommended parameters.

   • scope: (Required) OpenID Connect requests must contain the openid scope value. Other scopes may also be present

   • response_type: (Required) Determines the authorization processing flow to be used. When using the Authorization Code Flow, this value is code. When using the Implicit Flow, this value is id_token token or id_token. No access token is returned when the value is id_token

   • client_id: (Required) Client identifier that is valid at the OpenID Connect Provider.

   • redirect_uri: (Required) Redirection URI to which the response will be sent. This value must exactly match one of the redirection URI values for the registered client at the OP.

   • state: (Recommended) Opaque value used to maintain state between the request and the callback.

   • nonce: (Required for the Implicit Flow) String value used to associate a client session with an ID token and to mitigate replay attacks.

   We can include more parameters in the request. For a description of other supported parameters, see the OpenID Connect Core 1.0 specification.

   We do not support only an id_token response_type. Using the implicit flow must always use id_token token and will return an access token.

2. Send the GET or POST request to the authorization endpoint URL.

Results

After completing these steps, we have a valid HTTP request that is being sent to the authorization endpoint. The authorization endpoint returns a response in the manner described in the Examples section.

The OpenID Connect Provider attempts to authenticate and authorize the user once it receives a request from the client.

In the Authorization Code Flow, if authentication and authorization succeed, the OpenID Connect Provider issues an authorization code and includes it as a parameter in an OAuth 2.0 Authorization Response to the client. If the initial request included state, the authorization response will also include the exact state value that was included in the initial request. Using the application/x-www-form-urlencoded format, the code and state parameters are added as query parameters to the redirect_uri value that was specified in the authorization request.

In the Implicit Flow, if authentication and authorization succeed, the following parameters are returned from the authorization endpoint.

• access_token: Access token. This is returned unless the [response_type] value in the initial request is [id_token].

• token_type: OAuth 2.0 Token Type. For OpenID Connect, this value is Bearer.

• id_token: ID token.

• state: Required if included in authorization request.

• expires_in: (Optional) Expiration time of the access token in seconds since the response was generated.

These parameters are added to the fragment component of the redirect_uri value specified in the authorization request, not as query parameters such as in the Authorization Code Flow.

Example

The following examples show forms of Authorization and Implicit code flow.

An example request for the Authorization Code Flow is shown here:

 GET /authorize?
     response_type=code
     &scope=openid profile email   
     &client_id=client01   
     &state=af0ifjsldkj   
     &redirect_uri=https://server.example.com:443/oidcclient/redirect/client01 HTTP/1.1  

An example request for the Implicit Flow is shown here:

 GET /authorize?
     response_type=id_token token
     &scope=openid profile  
     &client_id=client01   
     &state=af0ifjsldkj   
     &redirect_uri=https://server.example.com:443/oidcclient/redirect/client01   
     &nonce=n-0S6_WzA2Mj HTTP/1.1  

An example response from the authorization endpoint in the Authorization Code Flow is shown here:

 HTTP/1.1 302 Found
 Location: https://server.example.com:443/oidcclient/redirect/client01
     code=SplxlOBeZQQYbYS6WxSbIA
     &state=af0ifjsldkj

An example response from the authorization endpoint in the Implicit Flow is shown here:

 HTTP/1.1 302 Found
 Location: https://server.example.com:443/oidcclient/redirect/client01
     access_token=SlAV32hkKG
     &token_type=Bearer   
     &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso   
     &expires_in=3600   
     &state=af0ifjsldkj

Parent topic:

Configure an OpenID Connect Client

Concepts:

OpenID Connect

OAuth

Tasks:

Invoking the Token Endpoint for OpenID Connect

Invoking the Introspection Endpoint for OpenID Connect

Invoking the UserInfo Endpoint for OpenID Connect