The OIDC Provider from BankID supports two classes of Access Tokens.
- By-reference tokens in terms of standardized Bearer Tokens. Tokens of this kind comes with corresponding support for Introspection to determine the Authorization Context for any particular bearer token value.
- By-value tokens in terms JSON WebTokens (JWT) that are signed (JWS) and optionally also encrypted (JWE). Tokens of this kind are self-contained as the token value contains all required information to determine the Authorization Context.
The Authorization Context referes to the following characteristics of the Access Token:
- The issuer (
iss)
of the access token - The subject (
sub)
of the access token - Intended audience (
aud)
for the access token - Active state / expiry (
exp)of
the access token - cccc (
client_id)
ccc - The specific set of Scopes and Claims associated with the access token
ccccc
token_type = bearer
bearer
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).