The below figure shows a simplified view of a authorization code flow for OpenID Connect Provider from BankID. The following core concepts concern various parts of this message flow.

Further details on browser re-direction, available REST APIs for customization of user-experience and any possible intermediate service between the end user and the OIDC client application are provided under advanced topics.

The following actors are involved:

End-user - The user owns resources that the OIDC Client requests access to. Most resources require an explicit consent from the user before the OIDC Client is granted access.
OIDC Client - The application that needs to assure the identity of the end-user and (optionally) requests access to a Value-added Service (VAS).
OIDC Provider - The platform from BankID that provides an OpenID Connect / OAuth2 interface in front of a range of Identity Providers (IDPs) and Value-Added Services (VAS).
IDP Service - A designated IDP among all IDP options supported by the OIDC Provider.
VAS Module - A module in the OIDC Provider that is responsible for Consent Handling for the VAS in question.
VAS Service - A Value-added service that returns data on the end-user beyond what is returned directly in the ID Token by the OIDC Provider itself. The service performs consent handling before actual data is retrieved subsequently.

The flow consists of the following steps, some of which are optional. Note that this example corresponds to an OAuth2 authorization code flow. The other oauth flows (implicit and hybrid) are not supported.

The end-user selects a user action at the OID Client that involves identification .
The OIDC Client requests indentification via the OIDC Provider at the authorize endpoint. The OIDC Client needs to authenticate itself in this request. A set of Scopes is also provided in this request to speciify requested Claims in the resulting ID Token and/or to request an Access Token to gain subsequent access to a Value-added Service (VAS).
The OIDC Provider sends an authentication request on to the Identity Provider (IDP) in question. The default IDP user experince without any customization is used in this case.
The IDP replies back to the OIDC Provider after sucessful authentication of the end-user
If the requested Scopes demand Consent Handling control is relayed on to the corresponding VAS-module in the OIDC Provider. The default Consent user experince without any customization is used in this case.
The VAS-module returns control back to the OIDC Provider after Consent Handling
The OIDC Provider returns an authorization code in the autorize response back to the OIDC Client.
The OIDC Client request the tokens via the OIDC Provider at the token endpoint, using the code provided. The OIDC Client needs to authenticate itself in this request
The OIDC Provider respond with the issued tokens:
1. an Access Token corrsponding to the requested Scopes and according to the result of Consent Handling in a preceding step.
2. an ID Token containing Claims according to the requested Scopes. The ID Token is signed to preserve its integrity.
The OIDC Client requests VAS-specific data using the Access Token to gain access
The VAS-service in question requests validation of the Access Token via the OIDC Provider at the introspection endpoint
The OIDC Provider responds with the result from token validation.
The VAS-service responds with the requested VAS-data if validation of the Access Token was sucessful.
The OIDC Client has identified the end-user along with VAS-specific data and resumes its business logic

Browser not supported