Consent flow improvements

Akoya is committed to providing a superior customer experience—that means ensuring optimal data access performance for everyone on the network.

To continue reaching our shared performance and compatibility goals, we’re making a change to how we authorize end-users and generate tokens by moving data recipients to a new token identity provider (IdP). The new IdP will improve Akoya’s network performance and will offer more flexibility with scoped client credentials and token life cycles.

Akoya will fully manage the migration of recipients from our existing IdP to the new one in a gradual, phased approach starting in our Sandbox.

A beta release is expected in our production environment in Q3 2023, but official timelines will be communicated in another announcement. This is still to be determined.

📘

If you feel this change will necessitate Akoya assistance, please reach out to your assigned Customer Success Manager.

What’s changing?

The Akoya authorization URL and Token API responses should not have substantive changes that would impact your implementation. The changes to note will be in the ID token (a JSON Web Token). There will be additional standard JWT claims and new custom Akoya claims.

❗️

Do you currently use the claims in the ID token?

If the answer is “yes” and your claims extraction is tightly coupled to the available claims and its structure, then the Akoya token and/or this update will impact you. Please reach out to your Akoya Customer Success Manager.

📘

If you do not use claims in the Id token, these improvements should not require action by you.

Versioning

For all parts of the consent flow—including the authorization URL, token responses, and JWT claims—please plan for non-breaking changes as Akoya continues to improve its network.

The following are non-breaking changes that may occur in this and future consent flow improvements:

• Addition of net-new claims in the id token
• Changes to the order of claims in the id token
• Changes to the length or format of opaque strings, such as resource IDs

For more on versioning, see: Versioning

Akoya ID JWT Claims

The following claim types will be optionally supported by Akoya. As per our Versioning guidelines, allow for additions as Akoya may add claims for future offerings.

Mandatory Claims

• connectorId - Akoya claim which lists the provider id
• recipientId - Akoya recipient id
• products - Akoya products permissioned by the end-user
• name - End-user's name in displayable form
• sub - Unique value to identify the end-user with the scope specific to the data provider.
• iss - Issuer identifier, Akoya URL
• exp - Time token will expire in Unix Epoch format
• iat - Time the JST was issued in Unix Epoch format
• aud - Data recipient (GUID)

Optional Claims

• accounts - Akoya claim which lists the accounts permissioned by the end-user. This claim is OPTIONAL and will not always be present

The above list is not exhaustive. For more on standard claims: see the JSON Web Token Claims specification.

Example Id Token

The following example uses mikomo_6 in the Sandbox.

{
  "accounts": [
    "1700080179",
    "722148112",
    "1506439401",
    "1931314440",
    "1764334283",
    "1048765182",
    "1051344706",
    "1563794797"
  ],
  "at_hash": "EXwZWGTuJoikPMZZpLYnpg",
  "aud": [
    "2157df70-e971-4dab-bb86-b9eb7ab5c4b6"
  ],
  "auth_time": 1689794649,
  "connectorId": "mikomo",
  "exp": 1689881094,
  "iat": 1689794694,
  "iss": "https://sandbox-sts.ddp.akoya.com",
  "jti": "66d2f82d-e0b5-4ed0-a6d6-750a222c4e66",
  "name": "mikomo_6",
  "products": [
    "provider_mikomo",
    "global",
    "provider_mikomo"
  ],
  "rat": 1689794644,
  "recipientId": "fintech_app",
  "sid": "fdeb202f-c8aa-4590-b36f-ecfd2ba02860",
  "sub": "CghtaWtvbW9fNhIGbWlrb21v"
}