The AML Service can be used with two different access token variants in accordance with the two variants supported by the AML servicethree different variants of end user authentication requires usage of different kinds of access_tokens, in conjunction with different types of message flows.
Variant | Message flow / type of access token |
---|---|
Variant 1: End user authentication via OIDC | authorization code flow or implicit flow |
Variant 2: End-user authentication embedded in BankID SDO | client credential grant flow |
Variant 3: Assessment of individuals without BankID identification | client credential grant flow |
In variant 1 the end user is directly referenced in the issued access token, which means the token contains everything the AML resource server needs to identify the individual.
In variant 2 and 3 the token contains no information about the actual end user. The client must in stead provide the end user identification through separate request parameter in the API. See separate AML API documentation.
Variant 1: End-user authentication via OIDC
This variant of the AML service uses the default Access Token format of the OIDC Provider from BankID. OIDC Clients can request Access Token for a given end user by supplying appropriate scope values in an Authorize request. The Access Token must be added as an Bearer Token to subsequent requests to endpoints for the AML API.
Warning | ||
---|---|---|
| ||
Note that the AML Service currently requires that the standard scope |
The following is an example of a valid Access Token for this variant of the AML Service. The resource designator aml_person
is added to the resource_access
claim of the access token to signify access to the endpoints of the AML API. Note that that realm_access
to to the standard scope profile
and and the custom scope nnin_altsub
are are also added.
Code Block | ||
---|---|---|
| ||
{ "sub": "83e54dbd-23a1-4e04-8e7f-6649c7db0473", "resource_access": { "aml_person": { "roles": ["basic"] } }, "birthdate": "1966-12-18", "allowed-origins": [], "amr": "BIM", "iss": "https://oidc.bankidapis.no/auth/realms/prod", "typ": "Bearer", "bankid_altsub": "9578-5999-4-1765512", "given_name": "Frode Beckmann", "nonce": "somecorrelationnonce", "aud": "aml_person", "acr": "4", "nbf": 0, "realm_access": {"roles": [ "nnin_altsub", "profile" ]}, "azp": "oidc-testclient", "auth_time": 1528868516, "name": "Frode Beckmann Nilsen", "exp": 1528868817, "session_state": "a92320b3-520f-40be-a749-66cf1a937c51", "iat": 1528868517, "family_name": "Nilsen", "jti": "2890d456-31a3-4bd2-b8e3-3b1b71cfe8f0" } |
Variant 2
...
and variant 3
These variants of the AML service uses the default Access Token format of the OIDC Provider from BankID, adapted to the Client Credential flow that is used by this variant.
...
The following is an example of a valid Access Token for this variant of the AML Service. The resource designator aml_person
is added to the resource_access
claim of the access token to signify access to the endpoints of of the AML API.
Code Block | ||
---|---|---|
| ||
{ "jti": "02354fbf-3965-400d-9463-0b8f6ad0cdfd", "exp": 1528869713, "nbf": 0, "iat": 1528869413, "iss": "https://oidc.bankidapis.no/auth/realms/prod", "aud": "aml_person", "sub": "7bcdcd53-7444-48c0-a70f-304ccfe847a7", "typ": "Bearer", "azp": "oidc-testclient", "auth_time": 0, "session_state": "e75f9937-1ab3-47e8-acd8-973794b1a746", "acr": "1", "allowed-origins": [], "resource_access": { "aml_person": { "roles": [ "basic" ] } }, "clientId": "oidc-testclient", "clientHost": "80.86.138.154", "clientAddress": "80.86.138.154" } |