CIBA-receive idToken

🔃 Polling the /token endpoint

Now the polling phase can begin. Your backend can start polling our “/token” endpoint

⚙️ API Request Example

Bash
curl --location --request POST 'https://www-identtest.nets.no/oidc/token?grant_type=urn:openid:params:grant type:ciba&auth_req_id=7d080d66b23e4ec1ad9ea1a238e741ef' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Base64Encoded username:password'

Ensure that Base64Encoded username:password is replaced with your actual Base64 encoded credentials

Polling interval and process expiration time is communicated to you when you make the initial call to the CIBA end point.

💬 Polling Response

While waiting for an ID token (that means that the process within the app is not finished yet so we do not have an ID Token to return to you) :

400 :{"error":"authorization_pending","error_description":"Consent confirmation is still pending"}”

After authentication, the ID token will be returned instead of the authorization pending message.

  • To avoid polling, you might do an implementation on your side which will only call our servers when your app informs you that the process in the SDK is finished. Our SDK will inform your app on this.

  • The ID Token will also contain a “access_token” parameter. You can use this in the next step of this process for calling the UserIfo end point and retrieve more information about the user and the transaction

🆔 ID Token info

A general description of the parameters within the idToken can be found here E-Ident APIs | InGroupe Doc

Look also for the section on the end for the “openid” scope OpenID Connect | InGroupe Doc

  • The idToken is signed by us. The customer must verify the signature ( jwks_uri for preprod: https://www.ident-preprod1.nets.eu/oidc/.well-known/jwk)

  • If the customer has requested token encryption for the MerchantId that is used for this connection, then this token will also be encrypted with the public key provided by the customer. The token must be decrypted first before the signature can be validated (see section on “ID Token encryption” in this document)

Example of an ID Token:

🔑 ID Token Details

JSON
"id_token": {
    "amr": [
      "trusted:pin"
    ],
    "sub": "trustid:d1323219",
    "iss": "https://www-ident-test.nets.no/oidc",
    "pid": "d1323219",
    "aud": "MER2",
    "exp": 1732717133,
    "iat": 1732716233,
    "jti": "ac05861215f8465caa91ec11f47ecd5e"
  }

The IDToken includes only standard OAUTH parameters

🔑 OAUTH Parameters

Information

Info

sub

i.e. "trustid:d1323219”
Subject Identifier.
A string in the format "eID type:ID" In this case:
• eID type = trustid”
• ID= “d1323219”:
o On a successful authentication/provisioning, it is the hashed Nets UserID of the authenticated user
o On any other case it is the unique transaction id of this process ( see parameter “jti”

jti

i.e. "ac05861215f8465caa91ec11f47ecd5e"
The unique transaction ID

pid

i.e. "d1323219",
The trustUserID of the user in a successful authentication

If the authentication fails , the “pid” parameter” is NOT returned

exp

i.e.
Expiration time on or after which the ID Token must not be accepted for processing.
The value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time

aud

i.e. "MER2"
The unique customer "MID" value.

iss

i.e. https://www-ident-test.nets.no/oidc
Issuer Identifier for the Issuer of the response. E-Ident issuer URI

amr

i.e. ["trustid", "trusted:pin" ]
Auth Method Ref. JSON array of strings that are identifiers for authentication methods used in the authentication. ( eID type:method).
For TrustID it will be “trusted:authentication:method” and it will one of the following values:
• trustid
• trustid:pin
• trustid:biometric
• trustid:pin_and_biometric

iat

i.e.
Time at which the JWT was issued.
The value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time

🔒 ID Token encryption

Customers can request us to encrypt all ID Tokens. The ID Token will be encrypted using RSA-OAEP-256 and AES, as described by RFC 7516. JWE Compact serialization is used and the encryption is done after signing, which means that the customer needs to decrypt the ID Token before being able to validate the signature.

The customer will need to provide us with one of the following options:
• A URL to a JWKS endpoint where Nets can look up a public key for encryption purposes. It is optional to also provide a key id. Otherwise, the first public key in the response from the endpoint will be used.
• The RSA key members and the key type in JSON format.

The use of encrypted ID Token is required for Finnish Trust Network customers offering identification with Finnish Bank IDs and Mobiilivarmenne.

jwks_uri for preprod: https://www.ident-preprod1.nets.eu/oidc/.well-known/jwk