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.
Updated about 1 month ago