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

Compare with Current View Page History

« Previous Version 12 Next »

The OIDC Provider from BankID supports two general classes of Access Tokens. 

  • Tokens by-reference in terms of standard Bearer Tokens. Tokens of this kind comes with corresponding support for Introspection to determine the Authorization Context for any particular bearer token value.
  • Tokens by-value 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 associated with the Access Token:

  • The issuer (iss)of the access token. See corresponding claim in ID Token.
  • The subject identifier (sub) of the access token, ie. a reference to the end-user (resource owner) that authorized the access token. See corresponding claim in ID Token.
  • Intended audience (aud)for the access token, ie. a reference to the service (resource server) that the access token regulates access to. Note that this is not related to the corresponding claim in the ID Token. The audience for the ID Token (being the OIDC Client) is different from the audience for an Access Token (being the Resource Server in question). 
  • Active state / expiry (exp)of the access token
  • The specific set of scopes and claims associated with the access token, ie. the set included in the Authorize request that subsequently resulted in the issuance of the access token in a reponse to a Token request

The particular Access Tokens supported by the OIDC Provider are specific for each of the supported Supplementary Services and described separately:

  • The Additional Information service uses a standard by-reference token of the bearer type.
  • The PSD2 Service involve a set of non-standard tokens, including both by-reference tokens and by-value tokens. 

 

----
Each class of 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).

  • No labels