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 options | Supplementary Services | Environment | |||||
---|---|---|---|---|---|---|---|
Pilot configuration | BankID | xID | Additional Information | PSD2 | Preview | Pre-prod | Prototype |
BankID pilot | X | X | X | X | X | ||
xID pilot | X | X | X | X | X | X | |
PSD2 pilot | X | X | X | X | X | X | X |
For further details on access URLs for each of the pilot configurations, see separate pages for BankID, xID and PSD2. See also source code on GitHub for various examples on how to implement OIDC Clients for the OIDC Provider from BankID.
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).