The OpenID Connect Provider from BankID is a platform supporting multiple Identity Provider (IDP) options, among them BankID and xID.

The platform provides ID Tokens for authenticated users and Access Tokens to authorize access to various Supplementary Services on behalf on the user.

The OIDC Provider is currently in pilot for evaluation purposes and shall not be used for commercial applications.

The platform may be augmented with more IDP options and Supplementary Service options in the future.

The OpenID Connect Provider from BankID (hereafter referred to as the OIDC Provider) is illustrated below. It consists of a industry-standard REST API in front of various Identity Providers (IDP) and Supplementary Services. The REST API is based on the OpenID Connect authentication standard on top of the OAuth 2.0 authorization framework. 

 

A major benefit of the OIDC Provider is to allow merchants start using the BankID Services with minimum integration effort compared to the legacy integration option (ie. install BankID Server, add a BankID merchant certificate and integrate towards the proprietary API of BankID server). For the xID Service  the OIDC Provider is the only integration option available to merchants. 

 

The  Additional Information service is available over the Userinfo endpoint according to the OpenID Connect specification and uses standardized scopes, claims and token formats . The PSD2 service does in contrasts consist of a range of specific OAuth2 scopes, claims and token formats tailored for various use-cases under PSD2.

 

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

 

 

See below for how to register an OIDC Client to gain access to the OIDC Provider from BankID. See also source code on GitHub for various examples on how to implement OIDC Clients for the OIDC Provider.

 

OIDC Clients may integrate directly with the OIDC Provider as shown in the below figure or indirectly via an intermediate party as described in a separate section. 

 

The OIDC Provider comes with a default component responsible for all GUI handling.  An OIDC Client may override the default GUI and provide its own customized GUI handling hosted at any URL.

 

 

Availability and access

The OIDC Provider is currently available in three different pilot configurations supporting various feature combinations. All features will be consolidated into one single configuration after the pilot phase. Each of the configurations are in turn available in different environments (preview, pre-prod, prototype).

 IDP optionsSupplementary ServicesEnvironment
Pilot configurationBankIDxIDAdditional InformationPSD2PreviewPre-prodPrototype
BankID pilotX X XXX
xID pilotXXX XXX
PSD2 pilotXXXXXXX


For further details on access URLs for each of the configurations, see separate pages for BankID, xID and PSD2
 

Please contact developer@bankidnorge.no to request access to any of the pilot configurations in any of the environments.

The following information must be supplied by the owner of the OIDC Client that requests access. Sucessfull enrollment will result in the return of a client_id and a client_secret to the application owner.

  • Description on what the OIDC Client is going to be used for
  • Contact information for both technical and commercial requests.
  • Optionally a BankID Merchant certificate to be used for the Client, thus replacing the default certificate of the OIDC Service itself.
  • Requested user properties or resources (scopes). 
  • One of more URLs where control will redirected back to the OIDC client (redirect URLs must be pre-registered for safety reasons).
  • A display name for the OIDC Client that will be shown in the header of the (default) OIDC dialogues.
  • Optionally an URL for custom GUI handling overriding the default GUI component of the OIDC Provider.

Characteristics of BankID OIDC access_tokens

Resources managed/authorized by the BankID OIDC Service get a “public” access_token (“one access_token to rule them all”). When an OIDC Client uses scope (or default scope) to define what resources it needs authorization for, the issued access_token can be used for all those resources. The resources must call the introspect endpoint in order to verify that it is the correct audience/resource for this access_token as well as getting returned the access_token contents/claims. Resources are expected to cache/cookie this information so there’s no need to call introspect for every incoming request with the same access_token.

The introspect endpoint demands basic authentication with the resource’s client_id and client_secret so that it knows what resource it is dealing with. 

Another policy is to have “private” access_tokens. That means each resource has their own access_token issued and encrypted with their client_secret/resource_secret. This would remove the need to call introspect in order to validate and get claims, but it will be difficult for the client to keep track of all the access_tokens issued to individual resource services. AAD is doing this and using the refresh_token to ask for more scope (new resources). This would work as long as the refresh_token is issued for the same resource owner (end-user).

"Private access_tokens" are currently not supported. Refresh_tokens are also not implemented. The rationale is that the supported “public” implementation is considered to more efficient (provided the caching we mentioned).