The OpenID Connect Provider from BankID (hereafter referred to as the OIDC Provider) consists of an industry-standard REST API in front of various Identity Provider (IDP) and Value-Added Service (VAS) options. 

The figure shows current and targeted IDP- and VAS options. See the Release Notes for futher information on supported IDP- and VAS options in this particular release of the OIDC Provider.

A good way to start exploring the OIDC Provider from BankID and its capabilities is as follows:

  • Carefully read this set of documentation on the OIDC Provider from BankID
  • Consult relevant internet resources on OAuth2 and OpenID Connect for additional/background reading.
  • Try out live example clients and also consult GitHub for source code examples

OIDC Intro

The term OIDC Client is used for any application that integrates with the OIDC Provider, corresponding to the following terms in related vocabularies:

  • OAuth2 clients in OAuth vocabulary
  • Relying Party in OIDC vocabulary
  • Merchant in BankID vocabulary
  • ASPSPs or TPPs in PSD2 vocabulary.

OIDC Clients must be provisioned (pre-configured) in the OIDC Provider in order to gain access. See the Release Notes for futher information on the provisioning process for this particular release of the OIDC Provider. An OIDC Client may integrate directly with the REST API, or  indirectly via a Javascript API referred to as the JS Connector. The latter simplifies integration for front-end applications.

OIDC Clients use Scopes and Claims to request content in ID Tokens and (optionally) request Access Tokens to gain subsequent access to Value-Added Services (VASs). Each VAS is associated with a VAS-module in the OIDC Provider and a separate VAS-specific Resource Server. The former is involved in consent handling whereas the latter implements VAS-specific endpoints to access various resources. Consent handling puts the end-user in control of delegating rights to an OIDC Client to access any VAS on behalf of the end-user. See Core Concepts for a closer description of these topics that are vital to understand before start using the REST API.

A major benefit of the OIDC Provider is to allow merchants start using the BankID service with minimum integration effort compared to the legacy integration option with BankID Server and its proprietary API.

The xID service, being a companion to BankID, offers zero- and one-click user experiences for applications that do not require the high security level offered by BankID. 

 The TINFO service provides end-user profile data according to the standard Userinfo endpoint. Access to resources behind this protected endpoint is governed by a standard Access Token and a set of standard Scopes and Claims. Some non-standard Scopes and Claims are also supported for profile data specific for the OIDC Provider from BankID. 

The PSD2 service consist of a range of (currently) non-standard Scopes, Claims and Access Tokens tailored for various use-cases under PSD2. In contrast to the TINFO service, note that the PSD2 service does not implement any corresponding Resource Server. PSD2 resources are made availble to AISP/PISPs over an APIs decided by each ASPSP.

xID plays an important role among all IDP-options since it can be used to derive the user ID that other IDP-options may depend on. Eg. when xID is used with BankID in this way, the end-user is reliefed from entering his national identity number (or phone number) in the first BankID dialgoue.

See advanced topics for further information on the following:

  • Message flow details
  • Indirect connection via an intermediate service
  • Customization of user-experience