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

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.

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.