Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

The OpenID Connect Provider from BankID rests on some core concepts that are best explained via the following figure on the involved message flow. 

Note that this figure is a simplified view that does not contain all 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. See separate sections under advanced topics for further information on such issues. 

 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 Hybrid flow. For other OAuth flows the message sequence will differ but are conseptually similar.

  1. The end-user selects a user action at the OID Client that involves identification . 
  2. 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).
  3. 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.
  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 experince 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 ID Token in the autorize response back to the OIDC Client containing Claims according to the requested Scopes. The ID Token is signed to preserve its integrity.
  8. The OIDC Client request an Access Token via the OIDC Provider at the  token endpoint. The OIDC Client needs to authenticate itself in this request
  9. The OIDC Provider respond with an Access Token corrsponding to the requested Scopes and according to the result of Consent Handling in a preceding step.
  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 sucessful.
  14. The OIDC Client has identified the end-user along with VAS-specific data and resumes its business logic



  • No labels