Core concepts

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. 

 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.
• 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.

1. The end-user selects a user action at the OID Client that involves identification . 
2. The OIDC Client requests identification 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
3. The OIDC Provider sends an authentication request on to the Identity Provider (IDP) in question. The default IDP user experience without any customization is used in this case.
4. The IDP replies back to the OIDC Provider after sucessful authentication of the end-user
5. If  the requested Scopes demand consent handling control is relayed on to the corresponding VAS-module in the OIDC Provider. The default Consent user experience without any customization is used in this case.
6. The VAS-module returns control back to the OIDC Provider after consent handling
7. The OIDC Provider returns an authorization code in the authorize response back to the OIDC Client.
8. 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
9. The OIDC Provider respond with the issued tokens:
   1. an Access Token corresponding 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.
   3. if requested by scope bankid_proof: a BankID Proof token containing end-user signature, end-user OSCP response and information used to build the message digest signed by the end-user.
10. The OIDC Client requests VAS-specific data using the Access Token to gain access
11. The VAS-service in question requests validation of the Access Token via the OIDC Provider at the introspection endpoint
12. The OIDC Provider responds with the result from token validation. 
13. The VAS-service responds with the requested VAS-data if validation of the Access Token was successful.
14. The OIDC Client has identified the end-user along with VAS-specific data and resumes its business logic