The OIDC Provider from BankID supports authentication via See the following set of IDPs. More IDP options may be added in the future. The last column shows if xID can be used in front of the IDP to derive any user ID that the IDP may depend on, thus simplifying user-experience.
...
LoA(acr)
...
Derive userID
via xID
...
BID
...
for more information on IDPs supported in this release of the OpenID Connect Provider from BankID:
| Children Display | ||
|---|---|---|
|
Each IDP option is associated with a Name and Level of Assurance (LoA) codified via attributes called amr (Authentication Method Reference) and acr (Authentication Context Class Reference), respectively. These attributes can be included in the request from an ODIC Client to the Authorize endpoint at endpoint at the OIDC Provider to request either a particular IDP (amr) or any IDP at a particular LoA (acr). A standard and designated request parameter exists for the acr attribute. Since there is no corresponding standard and designated request parameter for the amr attribute, the OIDC Provider from BankID supports amr values codified as part of the login_hint parameter.
Sucessful authentication via one of the supported IDPs results in an ID Token being returned to the reqesting OIDC Client. The ODIC platform from BankID provides Client. A key feature of the ODIC Provider is to return ID Tokens with uniform characteristics regarless of the IDP being used in any particular case.
Note that an ID Token also contain values for the amr and acr attributes, corresponding to the IDP actually being used. These values may be different from corresponding values provided in the request from the OIDC Client to the Authorize endpoint. One example is if more IDP options meet the amr/acr criteria of the Authorize request. In this case an IDP selector dialog is presented for the user to resolve which IDP to use. Another example is when xID performs a if the selected IDP involves step-up to BankIDanother IDP.
The OIDC Provider supports JavaScript Connectors See further details of separate pages for each of the supported IDPs how each IDP can be governed via login_hint or JS Connectors.. A connector is a wrapper for the REST API that simplifies integration for front-end applications and ensures that the REST API is used in the intended way. The supported Connectors have strong similarites but are also different according to the individual characteristics of each IDP.
Note finally that the user experience for any IDP may be customized depending on the specific policy and ruleset that applies for each IDP. See also general information on user experience and customization of user experience.
For further information, see separate sections on login_hint, JS Connector and Customization for each of the supported IDPs.