Unique Token Keys and Values

The uniqueness properties of id and refresh tokens, sub claims, and account ids can help fintech developers segment or map users in their own system. Unique values across the system can be used to keep data and consumer account linking in sync. This article outlines key components with unique values and some possible uses for these components. Your use case may be different, but these values can help tie together the consumer across systems.

id_token/refresh_token

The id_token and refresh_token are unique tokens in the system. No two are the same across apps, regardless of user. For more details about the format, storage, duration please see the Token Flow document. The id_token is a JWT token and contains multiple parts.

sub claim

The sub claim or sub is a unique identifier within the id_token. The sub claim has important properties for uniqueness. It is a unique identifier for the user for the issuing data provider. The sub claim remains consistent between refreshes and re-links for the same user.

The sub claim is one level more persistent than the id_token and refresh_token. The sub claim is persistent through a refresh. The tokens are not. This claim's persistent value can be leveraged if the consumer has to relink and you need to connect their previous sign in with the new sign in.

While every sub claim corresponds to an individual sign in with the data provider, each sub can represent multiple accounts that link to the same individual sign in. A user can have multiple sign-ins, for example, a separate personal account sign in and a separate business account sign in. The sub is only 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": "GenericUser_Pfm",  
  "email_verified": false,  
  "name": "KLDJFSDI4909DPSJNIO"  
}

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.

Changelog