Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space PDOIDC and version Paris_OIDC

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.

VariantMessage flow / type of access token
Variant 1: End user authentication via OIDCauthorization 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 identificationclient 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
iconfalse

Note that the AML Service currently requires that the standard scope profile and the custom scope nnin_altsub are is also added in the scope list along with aml_person/basic

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
languagexml
 {
  "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 This variant 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
languagexml
{
  "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"
}