Access Token¶

Structure¶

The default access token structure builds on Keycloak and consists of the following three parts:

A General part telling that the supported token type corresponds to standard Bearer Token usage
An ID part that contains key claims from the corresponding ID Token
An Access part that contains details on resource access, including in particular the audience (aud) for the access token.

The supported default token type is self-contained since it contains enough information to determine the authorization context, in particular the following:

The issuer (iss) of the access token.
The authorized party (azp) for the access token.
The subject identifier (sub) of the access token, ie. a reference to the end-user (resource owner) that authorized the access token.
Intended audience (aud) for the access token, ie. a reference to resource servers 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.
The specific set of resources that the access token grants access to, corresponding to the set of scopes included in the authorize request that subsequently resulted in the issuance of the Access Token.

Differences to Client Credential tokens

Note that access tokens for the Client Credential Grant have a different structure for the ID part since there is no ID Token involved in that case.

Claims contained in the JWT header are not shown. See session handling for the life-time of an access token. To cater for access tokens that are either revoked before their expiry, or that have expired prematurely for other reasons, validation of access tokens via introspect is supported.

Scopes and claims¶

The claims in the Access token is outlined in the table below.

Such claims are either added by Keycloak or the result of customization made by BankID.

Claim	Example	Description
General part
typ	Bearer	Token type. Always Bearer for Access Tokens.
allowed-origins	[]	Not in use by the OIDC Provider from BankID
ID part
acr	4	See ID Token
amr	API v1: BID API v2+: ["bid"]	See ID Token
auth_time	1510497762	See ID Token
azp	oidc_testclient	See ID Token
bankid_altsub	9578-0001-4-12341234	See ID Token
exp	1510498063	See session handling
iat	1510497763	See session handling
iss	<oidc-baseurl>	See ID Token
jti	7f22fd6a-3d46-4d5a-ae56-6de3c53e1873	See ID Token
nbf	0	See ID Token
nonce	<random value>	See ID Token
session_state	abf823c2-9810-4133-9369-7bff1223d6c1	See ID Token
sub	e8c523ff-52a2-42e2-a7a5-f1d0fbb76204	See ID Token
birthdate	1986-10-01	See ID Token
family_name	Nordmann	See ID Token
given_name	Kari	See ID Token
name	Nordmann, Kari	See ID Token
preferred_username	Nordmann, Kari	See ID Token
api_ver	2	See ID Token
Access part
aud	tinfo	Audience
realm_access	"roles": []	(deprecated) Resource access designator at the OIDC platform level.
resource_access	{"tinfo: {"roles": ["address","phone_number", "email", "nnin"]}}	Resource access designator.

Examples¶

Access token for electronic signing¶

The following is an example of a valid access token for the SignDoc resource server. The resource designator signdoc as well as the role read_write is added to the resource_access claim of the access token to signify access to the associated endpoint of the SignDoc resource server API.

{
  "exp": 1629281602,
  "iat": 1629281302,
  "jti": "7cc03090-7c8b-4775-9532-51169932adc7",
  "iss": "https://auth.current.bankid.no/auth/realms/current",
  "aud": "signdoc",
  "sub": "b9ce6414-2ddc-46e2-8330-7f3d59000c64",
  "typ": "Bearer",
  "azp": "oidc-testclient",
  "acr": "1",
  "realm_access": {
    "roles": []
  },
  "resource_access": {
    "signdoc": {
      "roles": [
        "read_write"
      ]
    }
  },
  "scope": "signdoc/read_write",
  "clientHost": "xxx.xxx.xxx.xx",
  "clientId": "oidc-testclient",
  "resource_claims": {},
  "clientAddress": "xxx.xxx.xxx.xx"
}

Access token for access to userinfo¶

Below is example of a valid Access Token for access to the Userinfo, used in context of the userinfo API. The resource designatortinfois added to theresource_accessclaim of the access token to signify access tovarious partsof the TINFO dataset. Since userinfo supports standardized claims, the same set of claims is also included underrealm_access.

{
  "sub": "2cd7cecd-d444-4685-bb04-8bbfdb45a069",
  "resource_access" : {
    "tinfo" : {
      "roles" : [ "address", "phone", "nnin", "profile", "email" ]
    }
  },
  "birthdate": "2018-05-09",
  "amr": ["bid"],
  "iss": "https://auth.current.bankid.no/auth/realms/current",
  "typ": "Bearer",
  "bankid_altsub": "9578-6000-4-634582",
  "originator": "CN=BankID - TestBank1 - Bank CA 3,OU=123456789,O=TestBank1 AS,C=NO;OrginatorId=9980;OriginatorName=BINAS;OriginatorId=9980",
  "given_name": "Test User",
  "nonce": "a6c03ff5-936c-4bff-ab98-a9898d37984f",
  "aud": "tinfo",
  "acr": "urn:bankid:bid;LOA=4",
  "realm_access": {
    "roles": []
  },
  "azp": "oidc-testclient",
  "auth_time": 1629280890,
  "scope": "openid phone address profile email",
  "resource_claims": {
  },
  "name": "Test User BankID",
  "exp": 1629281190,
  "session_state": "66801cef-7746-4dd6-a018-43bda5c7002b",
  "iat": 1629280890,
  "api_ver" : 2,
  "family_name": "BankID",
  "jti": "2fc59b32-e1ed-47cb-abf7-87786504912a"
}