Credential Tokenization | INFONITE

Refreshing somebody’s data every month should not mean keeping their bank password in your database. Tokenization moves that problem off your side without moving it wholly onto ours: the credentials are stored encrypted by the platform, under a key that only exists while you present the token you hold.

Neither half is enough on its own. That is the whole design, and it is worth understanding before you decide whether to use it — because it also decides what happens when something goes wrong.

Tokenization is enabled per application. Ask support to turn it on. Today it is available for direct executions; it is being extended to the widget flows where it makes sense — Bank Reader first — and this page will stay the single explanation of how it works.

The two halves

You ask for a ticket

When you run an access for the first time, you ask the execution to tokenize it. What comes back is a ticket: single-use, short-lived, and useless for anything except the next step.

You exchange it, once

The exchange returns a token id and a token key — a 64-character random string, generated at that moment. It is handed to you exactly once and it is never shown again, by any screen, endpoint or person.

From then on, you send the token

Every later run presents the pair instead of a password. The credentials themselves never travel back to you, and never travel to you at all.

Who	Holds	What it is
You	`token_id` + `token_key`	The key half. Store it as you would a password: encrypted at rest, out of your logs.
INFONITE	The encrypted credentials, and a verifier of your key	Ciphertext, plus enough to check that a presented key is the right one — never the key itself.

How the encryption works

This is the part that makes the split real rather than a promise.

The key you hold is not the encryption key

Your token_key is never used directly to encrypt anything. It is one input to a derivation: HMAC-SHA256 over your key, under a secret that lives only in our runtime environment. The result is the 256-bit key that actually opens the credentials, and it exists only for the moment it is used — it is never written down, on either side.

The credentials are sealed with it

AES-256-GCM, authenticated encryption: a byte altered in storage makes the decryption fail loudly instead of returning something plausible.

Your key is stored as a verifier, not as a key

What we keep beside the ciphertext is a scoped, non-reversible HMAC of your token key, compared in constant time when you present it. It proves the key is right. It cannot produce the key, and it cannot open anything.

What that means in practice

Scenario	Can the credentials be read?
We hold the ciphertext, you hold your key	Yes — during your call, and only then.
Somebody obtains our stored data alone	No. The derivation needs your token key, which is not there.
Somebody obtains your token key alone	No. There is nothing to decrypt without our stored data.
Somebody obtains both — ciphertext and key	Still not, without our environment’s secret and the exact derivation. That is the third factor, and it lives in neither of the two places an attacker would look.
You lose your token key	Nobody can. Not you, not us, not support. See below.

This is shared responsibility, in the exact sense of the term. You are not handing us your customers’ credentials to look after; you are keeping the half that makes them readable. It also means the protection is only as good as how you store token_key — the one thing we cannot do for you.

Losing the key is final, and that is deliberate

There is no recovery path, no support ticket and no override. If the token key is lost, the stored credentials become bytes nobody can open — including us.

What to do: revoke the token and mint a new one from a fresh run with the real credentials. That is the only way back, and it involves your customer, because it involves their password.

Design for that before it happens. A token key living in exactly one place, with no backup and no rotation plan, turns a routine database migration into a re-onboarding of every customer. Store it as you store any other secret you cannot recreate.

What a token can do, and for how long

A token is not a general-purpose credential. Its scope is fixed at the moment it is minted, and it can be narrowed later but never widened:

Locked to	Meaning
One application	Yours. The token is meaningless without your application secret alongside it.
One source	The engine that produced it.
One customer	The `customer_id` of the original run.
A set of features	Ask for fewer on a given run if you like; asking for one outside the original scope is refused.

It expires 90 days after the exchange, and using it does not extend that. The expiry is decided when the token is minted; when it arrives, the stored credentials are deleted. Track it and re-mint before it lapses — a quarterly job that never re-mints works for three months and then fails for everybody at once.

A token can also be locked by the source: if the institution rejects the stored credentials or blocks the account, the token stops running and says so. Retrying does not help and can make it worse — institutions count failed attempts. That is a conversation with your customer, and it ends in a new token.

Revoking

Revocation is immediate and irreversible: no execution can use the token afterwards, and the stored credentials are marked for deletion. Call it when a customer withdraws consent, closes their account with you, or asks you to stop — and after any suspicion that your half leaked.

Your customer’s right to be forgotten is two calls, not a support ticket. Revoke the token, delete the executions that used it. Both are immediate, and neither needs us.

Where to do all of this

Direct Executions

The endpoints: asking for a ticket, exchanging it, running with a token, reading its status and revoking it.

Payload Encryption

The other half of the crypto story — how what we send you is encrypted, and how what you send us travels.