Note finally that the OIDC Provider form BankID supports signed Access Tokens in JWT format. The below table shows claims in the payload part of the JWT. 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 is supported. Another use of introspection is for eligible resource servers to retrive retrieve confidential claims that are not carried in the access token itself. One such examle is the bankid_altsub claim.

The claims in the Access token is outlined in the table below. The origin column indicates non-standard claims. Such claims are either added by Keycloak or the result of customization made by the BankID OIDC Provider.

Claim	Origin	Scope	Example	Description	Comment
General part
`typ`	Keycloak	none required	`Bearer`	Token type	Always `Bearer` for Access Tokens
`allowed-origins`	Keycloak	none required	[ ]	Not in use by the OIDC Provider from BankID
ID part
`acr`	Standard	none required	`4`	See ID Token
`amr`	Standard	none required	`API Version 1: BID` `API Version 2 onwards: ["bid"]`	See ID Token
`auth_time`	Standard	none required	`1510497762`	See ID Token
`azp`	Standard	none required	`oidc_testclient`	See ID Token
`bankid_altsub`	Custom	none required	`9578-5999-4-1765512`	See ID Token
`exp`	Standard	none required	`1510498063`	See session handling
`iat`	Standard	none required	`1510497763`	See session handling
`iss`	Standard	none required	`<oidc-baseurl>`	See ID Token
`jti`	Standard	none required	`7f22fd6a-3d46-4d5a-ae56-6de3c53e1873`	See ID Token
`nbf`	Standard	none required	`0`	See ID Token
`nonce`	Standard	none required	`<random value>`	See ID Token
`session_state`	Keycloak	none required	`abf823c2-9810-4133-9369-7bff1223d6c1`	See ID Token
`sub`	Standard	none required	`e8c523ff-52a2-42e2-a7a5-f1d0fbb76204`	See ID Token
`birthdate`	Standard	none required	`1966-12-18`	See ID Token
`family_name`	Standard	`profile`	`Nilsen`	See ID Token
`given_name`	Standard	`profile`	`Frode Beckmann`	See ID Token
`name`	Standard	`profile`	`Nilsen, Frode Beckmann`	See ID Token
`preferred_username`	Standard	`profile`	`Nilsen, Frode Beckmann`	See ID Token
api_ver	Custom	none required	1	See ID Token
Access part
`aud`	Standard	none required	`tinfo`	Audience	List of VAS-names for which the access token in question is intended
`realm_access`	Keycloak	`profile` `address` `phone` `email nnin_altsub` `nnin`	`{"roles:` `["profile","address","phone","email","nnin_altsub","nnin"]` `}`	Resource access designator at the OIDC platform level.
`resource_access`	Keycloak	`profile` `address` `phone` `email` `nnin`	{"tinfo: {"roles ["address","phone_number", "email", "nnin"] }}	Resource access designator.

Examples

Access token for electronic signing

...

Code Block

language	js

{
    "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 TINFO resource server, used in context of the api-userinfo API. The resource designator tinfo is added to the resource_access claim of the access token to signify access to various parts of to various parts of the TINFO dataset. Since api-userinfo Userinfo (TINFO Userinfo Endpoints) supports standardized claims, the same set of claims is also included under realm_access.

Code Block

language	js

{
    "sub": "2cd7cecd-d444-4685-bb04-8bbfdb45a069",
    "resource_access": {
        "tinfo": {
            "roles": [
                "address",
                "phone",
                "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": [
            "address",
            "phone",
            "profile",
            "email"
        ]
    },
    "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,
    "family_name": "BankID",
    "jti": "2fc59b32-e1ed-47cb-abf7-87786504912a"
}

Other notes

Warning

To be prepared for a possible future change from multi-audience access tokens to single-audience access tokens, OIDC Clients are recommended to not include a set of scopesin the same request that affects more that one VAS. The recommended integration practise is to use a series of subsequent requests for access tokens to separate VAS. Using this recommended integration practise will not break backwards compatibility if a single-audience restriction is introduced. For authentication flows involving the end-user subsequent requests can be made via the id_token_hint option for the Authorize endpoint to avoid repeated authentication of the end-user.

Note that the OIDC Provider from BankID currently supports multi-audience tokens. If an OIDC Client requests a set of scopes that affect several resource servers, each of the affected services will be listed in the aud claim of the access token.

This practise may be changed in a future release of the OIDC Provider from BankID by imposing a restriction to not allow requests for a set of scopes that affect more than one VAS in each request. Introducing such a single-audience restriction has the benefit of giving tighter control since a bearer token in wrong hands gives access to fewer resources. The downside of a single-audience restriction is that integration becomes more complex for OIDC clients since multiple requests must be made, one for each set of requested scopes, to get a series of access tokens, one for each affected VAS.To be prepared for a possible future change from multi-audience access tokens to single-audience access tokens, OIDC Clients are recommened to not include a set of scopesin the same request that affects more that one VAS. The recommended integration practise is to use a series of subsequent requests for access tokens to separate VAS. Using this recommended integration practise will not break backwards compatibility if a single-audience restriction is introduced. For authentication flows involving the end-user subsequent requests can be made via the id_token_hint option for the Authorize endpoint to avoid repeated authentication of the end-user.

Version	Old Version 10	New Version Current
Changes made by	Janny Kinende	Matheus Srebro
Saved on	21 Jun 2022	22 Aug 2023

Page Comparison

Versions Compared

Key

Examples

Access token for electronic signing

Access token for access to userinfo

Other notes