OIDC Authentication - Recap

To better understand what the IDP Kit does, let's first recap on the basics of OIDC authentication flows.

For more details, visit the OIDC specification.

OIDC authentication flows

In a usual OIDC authentication flow, the client application makes an authentication/authorization request to an authorization server or identity provider. In this request, the client includes the scopes and/or claims, which define the pieces of information about the user required by the application.

The identity provider redirects to a login or authentication page, where the user has to authenticate and give their consent to the requested information being shared with the application.

Depending on the response type chosen by the application, the identity provider will provide an authorization code, which can be traded for an access token and ID token, or the respective tokens directly, by calling the redirection URI of the application with the respective parameters.

The application can use the access token to retrieve the user information, which was originally requested. The id token usually contains a user ID, issuer ID, expiration date, etc., which the application can use at it's own discretion.

Code flow

The application requests response_type=code in the authorization request, and receives an authorization code from the identity provider, which can be traded for access_token and id_token on the token endpoint. Using the access_token the application can retrieve the requested user information over the userInfo endpoint.

Communication with the identity provider is usually done via a backend of the client application and requires client authentication.

Code flow

Implicit flow

The response_type requested by the application is id_token token, id_token or token, and the identity provider sends the requested tokens directly to the callback uri of the client application. The application can use the access_token to retrieve the requested user information over the userInfo endpoint. If only id_token was requested by the application, the user information is included in the id_token returned by the identity provider.

This flow is usually chosen if the application front-end conducts the user authorization without any backend interaction.

Code flow

Hybrid flow

In a hybrid flow, the client application requests any combination of code, id_token and token response types and has the option to follow the implicit or code flow to retrieve user information according to the specific requirements.

OIDC scopes and claims

An OIDC authentication request usually contains a set of scopes and/or claims requested by the client application.

Scopes usually imply a predefined set of claims, whereas a claim is a request for a specific piece of information about the user.

For a full list of standard claims and scopes, please take a look at the OIDC specification.

Example scopes:

• profile

  • Claims: name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, and updated_at

• email

  • Claims: email, email_verified

• address:

  • Claims: address

• phone:

  • Claims: phone_number, phone_number_verified

Example request

The following non-normative example authentication request is taken from the OIDC specification.

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

This example request consists of the following parameters:

• response_type: The response_type requested by the application

  • In this case an authorization code is requested.

• scope: The requested scopes defining the information requested by the application:

  • openid: default scope, that is always included in OIDC requests

  • profile: request user profile information (see above)

  • email: request user's email address and whether the email address had been verified (see above)

• client_id: The ID of the client application, as it was registered with the identity provider

• state: Arbitrary state information of the client application, that is propagated to the authentication response on the callback/redirection URI.

• redirect_uri: Redirection or callback URI of the client application, which will be called with the authentication response (in this case: the authorization code) in the URI parameters