You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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).

  • No labels