OIDC Authentication - Recap
Last updated
Last updated
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.
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.
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.
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.
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.
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
The following non-normative example authentication request is taken from the OIDC specification.
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.
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
