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_token/refresh_token

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.

sub 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 sign ins to a single data provider (i.e. one personal sign in, one business sign in). This value will be unique for each sign in.

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

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 sign in with the new.

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

accountId

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.

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.