The below figure shows an example protocol flow that is currently supported by the OIDC Provider, corresponding to an hybrid flow in OAuth2 vocabulary. Support for other OAuth2 flows (code grant flow and implicit grant flow) will be added in future versions of the OIDC Provider.  

The following applies for this particular example:

• The OIDC Client uses the default GUI of the OIDC Provider
• The OIDC Client leaves selection of IDP Option to the End User in a selector dialogue provided by the OIDC Provider
• The OIDC Client requests access to reseources that is available via the Additional Info Supplementary Service.

The following color coding is used:

• Red corresponds to application-specific flows for the OIDC Client
• Blue corresponds to standardized flows according to the OpenID Connect and OAuth2 specifications.
• Black corresponds to specific flows for the OIDC Provider from BankID
• Yellow corresponds to specific flows for the designated IDP.
• Green corresponds to specific flows for any Supplementary Service (Additional Info in this particular example).

Note that an OIDC Client only concerns standardized flows (blue color) with the OIDC Provider. The exception is if the OIDC Client wants to override default GUI handling. Any component responsible for customized GUI handling must integrate with a specific REST API (black color) of the OIDC Provider. Any such component must in addition take care of proper integration with each of the supported IDP options (yellow color).

The following actors are involved in the protocol flow:

• End user - The user owns resources that the OIDC Client requests access to. Some resources may require an explicit consent from the user before the OIDC Client is granted access.
• User-Agent  - A browser, or a browser window in an application, allowing the user to navigate the OIDC Client and interact with the other parties involved via re-direction of requests through the User-Agent.
• OIDC Client - The application that needs to assure the identity of the end user and request access to various resources. 
• OIDC Provider - The platform from BankID that provides an OpenID Connect / OAuth2 interface in front of a range of IDPs  and Supplementary Services.
• OIDC GUI - A service that is responsible for all GUI handling associated with OIDC Provider. The OIDC Provider comes with a default GUI service that is used unless it is overridden by the OIDC Client.
• IDP Service - A designated IDP selected by the End User among all IDP options supported by the OIDC Provider (in other cases the OIDC Client may select the designated IDP option).
  
• Additional Info Service -  A service, available over the standardized OIDC Userinfo endpoint, that returns additional information on the end user beyond what is returned directly in the ID Token by the OIDC Provider itself.

The protocol flow consists of the following steps, some of which are optional. (TODO: add hyperlinks to the below list)

1. The End User navigates the OIDC Client via the User-Agent and selects a login action.
2. The OIDC Client redirects the User-Agent to the OIDC Provider with an authorization request. Parameters to the request includes the ID of the OIDC Client, list of requested resources (scopes), a redirectURL to where control is to be returned - to name a few. The OIDC Client will regain control in step 16 at the designated redirectURL.
3. The OIDC Provider opens a session and redirects the User-Agent with an authentication request to the designated URL for GUI handling, which in this case corresponse to the default GUI component. Parameters to the request identifies the session in progress.
4. The GUI component requests parameters from the OIDC Provider for the session in progress to determine if the OIDC Client has pre-selected a specific IDP or if a selector dialog should be shown to the end user
5. A IDP selector dialog is (optionally) shown to the end user.
6. The GUI component sends an init request to the OIDC Provider for the designated IDP Service
7. The OIDC Provider sends a corresponding init request to the designated IDP Service which opens a session and responds with the necessary parameters to lauch the GUI for the designated IDP
8. The OIDC Provider returns the necessary parameters to the GUI component
9. The GUI component delivers the GUI for the selected IDP to the User-Agent
10. The End User interacts with the IDP GUI, which in turn communicates with the IDP Service. Note that the OIDC Client is kept out of this dialogue to prevent any replay attack from any malicious OIDC Client.
11. After completing the session with the IDP Service, the User-Agent is redirected back to the OIDC Provider with an authentication response. The End User is now authenticated.
12. The OIDC Provider redirects the User-Agent to the GUI component for consent handling
13. The GUI component requests from the OIDC Provider which scopes have been requested by the OIDC Client for the session in progress,
14. After analyzing how the requested scopes may demand explicit consent from the user, the required GUI dialog is returned to the User-Agent for the End User to give his consent.
15. The User-Agent is redirected back to the OIDC Provider at termination of the consent dialogue. The ID Token for the authenticated user is now being composed according to the reqested scopes.
16. The ID Token is retuned to the OIDC Client via a redirect of the User-Agent, corresponding to a hybrid OAuth2 flow. An intermediate authorization code is also returned in this step that is used in the next step to request any access token.
17. The OIDC Client exchanges the authorization code from the previous step for an access token with the OIDC Provider, which in this case is a token to gain access to the Additional Info Service over the Userinfo endpoint. Note that the request for an access token does not go through the User-Agent for security reasons. 
18. The OIDC Client sends the Access Token in a request to the OIDC Provider to get access to Additional Info via the Userinfo endpoint.  The Access Token is a bearer token that provides proof of authorization by the End User.
19. The OIDC Provider validates the provided access token via the Introspect endpoint.
20. After sucessfull validation of the Access Token, the OIDC Provider retrievs Additional Anformation from the back-end part of the service.
21. The Additional Information in question is returned to the OIDC Client in a Userinfo response.
22. The OIDC Clients returns to the User-Agent a page showing the reponse of the login request along with any Additional Information that was retrieved.