What It Actually Means
You meet them in two places. After you log in, your session is usually held as a token rather than by re-sending your password on every click. And when two systems talk to each other, the calling system presents a token instead of a username and password.
The characteristic that matters commercially is that a token is a credential in its own right. Whoever holds it has whatever it grants, with no further check. It does not care who is presenting it.
Why That Matters More Than It Sounds
Passwords get treated carefully because everyone understands what they are. Tokens get treated casually because they look like configuration.
They end up pasted into spreadsheets, committed into code repositories, sitting in chat history from when someone shared one to fix an urgent problem, and stored in the environment of a server nobody has logged into since it was set up. Each of those is a working key to something.
Repositories are the standard case. A token committed to git remains in the history after it is removed from the current files, and automated tools scan public repositories for exactly this, continuously. Discovery is measured in minutes.
The Properties To Check
Expiry. Short-lived tokens limit the damage of a leak to a narrow window. Tokens that never expire are permanent keys, and most of the ones your business holds are probably in this category.
Scope. A token should permit what the integration needs and nothing else. Read-only where read-only will do. A great many are created with full access because it was quicker and nobody revisited it.
Revocability. You should be able to invalidate one immediately without changing anything else. If revoking a token means changing a password used by four other things, it will not be revoked when it should be.
Rotation. Changing them periodically limits the value of one that leaked without anyone noticing. This is where the practical benefit of a proper secrets store shows up, because rotation by hand across a dozen systems does not happen.
What To Ask
- Where are our tokens stored? Environment variables or a secrets manager. Not in the codebase, not in a shared document.
- Has any token ever been committed to a repository? If yes, it must be revoked rather than deleted from the files. History persists.
- What can each one actually do? Full-access tokens for integrations that only read are the common finding.
- Could we revoke one today without breaking three other things?
- Who holds tokens for our systems? Every supplier and integration with an active token is standing access into your business.
The Practical Habit
Tokens accumulate. Every integration, trial, script and supplier adds one, and almost nothing removes them. Unlike staff accounts, there is no leaving date to prompt a clear-out.
An annual review of what holds a token, what it can do, and whether it is still in use catches genuine exposure and takes very little time. It is the same discipline as reviewing API keys and OAuth grants, and the three lists overlap heavily, so it is sensible to do them together.
More terms are in the glossary.
