...
The following is an example of a valid access token to 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.
...
| Code Block | ||
|---|---|---|
| ||
{ " |
...
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 the TINFO dataset. Since api-userinfo supports standardized claims, the same set of claims is also included under realm_access.
| Code Block | ||
|---|---|---|
| ||
{
"jtisub": "a48fecfe2cd7cecd-e4c8d444-48d34685-9a45bb04-b41ded9320338bbfdb45a069",
"expresource_access": 1520371229,{
"nbftinfo": 0, {
"iatroles": 1520370929, [
"iss": "https://oidc-preprod.bankidapis.no/auth/realms/preprod",
"aud": "tinfo",
"sub": "b3f4d919-8cc5-413c-9e11-3c2c675b2f8f",
"typ": "Bearer",
"azp": "oidc-testclient",
"nonce": "somecorrelationnonce",
"auth_time": 1520370929,
"session_state": "bf71d01f-3a7c-474a-92c7-6c395cb95fc6",
"name": "Frode Beckmann Nilsen",
"given_name": "Frode Beckmann",
"family_name": "Nilsen",
"birthdate": "1966-12-18",
"acr": "2",
"allowed-origins": [
""
],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",
"profilephone",
"email" "profile",
] }, "resource_access": { "tinfoemail":
{ "roles":]
[ },
"addressazp": "oidc-testclient",
"phone"auth_time": 1629280890,
"scope": "openid phone address "profile email",
"resource_claims": {},
"emailname": "Test User BankID",
] "exp": 1629281190,
} }"session_state": "66801cef-7746-4dd6-a018-43bda5c7002b",
"amriat": "XID"1629280890,
"preferredfamily_usernamename": "BankID"Nilsen,
Frode Beckmann", "bankid_altsubjti": "9578-6002fc59b32-e1ed-47cb-abf7-87786504912a"
} |
Other notes
| Warning |
|---|
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 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. |