Unique keys and values

Unique values across the Akoya DAN can be used to keep data and end-user account linking in sync. The following outlines keys with unique values and some possible scenarios where they’ve been used. Your use case may be different, but these values can help tie together the end-user across systems.

ID tokens & refresh tokens

The id_token and refresh_token are unique tokens in the Akoya system. No two are the same across apps, regardless of user or data provider. For more details about the format, storage, duration please see the Token Flow document.

The id_token is a JWT token, and as such has information inside of it. One of the most meaningful parts for uniqueness is the sub claim.

Unique per Akoya	Unique Data Provider	Unique Per User	Unique on Refresh
YES	YES	YES	NO

Subject claim

The sub (short for subject) claim is a unique identifier within the id_token. This is a unique identifier for the user for the issuing data provider and will remain consistent between refreshes and re-links for the same user.

Please note: The user may have multiple logins to a single data provider (i.e. one personal login, one business login). This value will be unique for each login.

{  
  "iss": "https://sandbox-idp.ddp.akoya.com/",  
  "sub": "CkExamplehtaWtvbP9fMRIGbWlrb21v",  
  "aud": "recipient",  
  "exp": 1626206304,  
  "iat": 1626119904,  
  "at_hash": "VZ_ExJP9zAhtWa5KxCTX-CQ",  
  "email": "mikomo_1",  
  "email_verified": false,  
  "name": "KLDJFSDI4909DPSJNIO"  
}

Unique per Akoya	Unique Data Provider	Unique Per User	Unique on Refresh
NO	YES	YES	NO

The sub claim value is not guaranteed to be unique throughout the Akoya system, just unique to the data provider. This claim's persistent value can be leveraged if the end-user has to relink and you need to connect their previous login with the new.

While every sub claim corresponds to an individual login with the data provider, each sub can represent multiple accounts.

Account ID

The accountId is tied to a specific claim and therefore a specific id_token/refresh_token. As the accountId(s) is unique per claim, this identifier helps to make sure the user is sharing the same account(s) and allows continuity between token refreshes.

Unique per Akoya	Unique Data Provider	Unique Per User	Unique on Refresh
NO	NO	YES	NO

The accountId is not guaranteed unique within the Akoya system at large and is not guaranteed to be unique across the data provider. It is meant to be unique and persistent for a given sub claim.

Need help?

Check out our Developer Community, or visit the Support Center in the Data Recipient Hub.

Looking for provider nuance documentation?

All provider nuance documentation is available in the Data providers section in the Data Recipient Hub.

Still stuck?

For all production issues, submit a support ticket through the Data Recipient Hub. Our support team is standing by 24/7. Questions and non-production issues will be answered during business hours.