Known issues

Known issues in this release of the OpenID Connect Provider from BankID are further described below in terms of:


The following table summarizes restrictions in the latest release of OIDC Provider from BankID:

R2Indirectly connected clients of the known-type via Intermediate Services are currently not supported. Such support is planned for a future release.

Some authentication method for OIDC Clients are not supported

R4Pure app-based applications using a completely embedded (API-based) user-experience is currently not supported. Such support is planned for a future release.
R7Offline Refresh Tokens via the offline_access scope is currently not provided

POST method is not supported by TINFO Userinfo endpoint

R10Implicit flow (and hybrid flow) is not supported as we do not support public clients, i.e. native apps and single page applications without a backend to perform token code exchange.
R11The amr claim in the ID token is a string value and not an array of strings. This is fixed in API Version 2.
R12Authorization code flow with PKCE is recommended (and it will be required in the upcoming OAuth 2.1 spec), but we only support it for confidential clients and NOT public clients (e.g. client secret is required). See R10 for more info.


The following table summarizes caveats in the latest release of the OIDC Provider from BankID:



C1The AML Person resource currently requires that the scope profile is provided along with the scope aml_person/basic in requests to the authorize endpoint.
C2Merchants should not use hardcoded base URLs for supported endpoints that are included in the response from openid-configuration. The recommended practise is to always use any endpoint URL that is contained in the output from openid-configuration.
C3The OIDC Provider currently support multi-audience access tokens but may change its support to single-audience token in the future. See the section on Access Tokens for further information on the recommended integration practise to be prepared for such a future possible change.
C4The nnin_altsub claim is never part of an Access Token regardless of the presence of this claim in the corresponding ID Token. Resource Servers that are entitled to receive nnin_altsub must be configred to for such access and retrieve this claim via introspection 

The default userinfo endpoint in Keycloak <oidc-baseurl>/protocol/openid-connect/userinfo is replaced by a corresponding userinfo endpoint for TINFO. The latter must be used and is reported in .well-known/openid-configuration. The default Keycloak userinfo still responds but does not contain any data that is not already part of the ID Token.

C6Access to certain scopes may be granted even if such scopes are not explicitly included in the request to authorize or token endpoints. This will happen if the OIDC Client is configured with access to such scopes, and such scopes are defined as default in the OIDC Provider.
C7Scopes requested via authorize  or token  endpoints may be silently ignored without any error to the OIDC Client if (i) the scope value is mis-spelled and (ii) the client in question is not configured for access to the scope(s) in question. To avoid mis-spelling, note that scopes values are case-sensitive.
C8The scope parameter is disregarded for Refresh Token requests to the token endpoint. Granted claims for a refreshed Access Token are always according to the scopes included in the original request to the authorize or token endpoints
C9The aud claim in Access Tokens and Refresh Tokens has a singleton-format and not a list-format (with a single entry) if there is only one audience involved. Hence, implementors must deal with both singleton-values and list-values for this claim.


The following table summarizes known bugs in the latest release of the OIDC Provider from BankID:

B1Language is sometimes not set according to the ui_locales parameter
B2The error response from TINFO Userinfo is not according to standard
B5There is a small anomaly with styling of OIDC-client in Microsoft Edge 41