OpenID Connect authentication
This page describes the authentication flows for using OpenID Connect to obtain an ID token or an access token.
Authorization code flow
The authorization code flow is an extension of the OAuth 2.0 authorization code flow.
-
The relying party (RP) obtains the authorization code from the authorization endpoint using a front channel, such as a web browser.
-
The RP exchanges this code at the token endpoint for an access token, ID token, or both. An RP that is capable of storing secrets securely does this through the back channel, with an authenticated request to the token endpoint. RPs that cannot store secrets securely, such as a single page app in the browser, call the token endpoint and use Proof Key for Code Exchange (PKCE).
To obtain the ID token in this flow, ensure that the web client has theAuthorization Code grant type and the openid scope configured. Create an OAuth authorization request with the openid scope.
Implicit Flow
The implicit flow is a one-step flow. The client requests an access token or ID token directly from the authorization endpoint using a front-channel, such as via a web browser. This workflow can be suitable for those clients that cannot store the client secret in a secure fashion, such as web applications running inside a user agent, like a web browser. However, this flow is no longer recommended. Use the authorization code flow with PKCE.
To obtain the ID token in this flow, make sure the web client has the Implicit grant type enabled and openid scope configured.
Create an OAuth authorization request with response_type=id_token and the openid scope.
Hybrid flow
The OneWelcome Identity Platform does not support the hybrid flow.
User interaction
The regular authentication flows assume that they are called when authentication is needed. When the user does not yet have a session with the identity provider (IDP), the user needs to perform some interaction, such as entering their credentials. When the user does have a session, the IdP redirects them back to the OneWelcome Identity Platform. This section describes several scenarios to obtain tokens using OpenID Connect.
Require login
If the user already has a session with the IDP, the IDP automatically returns the user information to the OneWelcome Identity Platform. There are situations where you want to force the user to log in again to obtain a token. For example, when the user changes personal data, or when another user wants to register for the same mobile app on a shared mobile device.
To require login, add the following request parameter to the authentication request: prompt=login.
Passive login
Some sites have publicly accessible pages that can show personalized content if the user is authenticated. It's not required to immediately log in, and therefore you want to avoid showing a login page until it is needed. You do want to benefit from having an access token or ID token if the user is logged in.
For this scenario, you can use the authorization code flow with a SAML-based IDP. If the user is logged in at the SAML IDP, and no user interaction is required, the OneWelcome Identity Platform issues an access token and an ID token.
To perform this passive login, add the following parameter to the authentication request: prompt=none.
You can use this passive login for session management with iframes.
Cookie-based login
Cookie-based login is similar to passive login, but the user does not need to have a valid session with the IDP. It requires the OneWelcome Identity Platform as the IDP. If the user has a cookie from a previous session, and no user interaction is required, the OneWelcome Identity Platform issues an access token and an ID token.
To perform the cookie-based login, add the following parameters to the authentication request:
prompt=none&external_idp=urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession.
