The three 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.

Note that the AML Service currently requires that the standard scope profile 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 realm_access to the standard scope profile and the custom scope nnin_altsub are also added.

 {
  "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. 

Eligibile OIDC Clients can request Access Tokens for the AML Service by invoking the Token endpoint using Client Credential Grant and supplying appropriate scope values. The Access Token must be added as an OAuth2 Bearer Token to subsequent requests to endpoints for the AML API.

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. 

{
  "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"
}
  • No labels