The Credential Inventory_

"Token" gets used for all five of these, which is exactly why they blur together in a notes file. They differ on three questions: who made it, who can read it back, and what happens when it changes. Place a value in one of these boxes and you always know what to do with it.

Kind 1 — Shared secret

A long random string acting as a password with no username. Whoever holds it is trusted completely, so it is only ever as safe as the place you keep it.

Kind 2 — API key

Issued by a vendor so their servers know which account to bill and rate-limit. You did not create it and cannot recreate the same one — you can only ask for another.

Kind 3 — OAuth token

The kind you never see. A user clicks "Allow" on a screen they recognise, and the service hands your application a token directly, behind the scenes. OAuth = Open Authorization, the standard behind every "Sign in with…" button.

Kind 4 — Minted key

A credential your own application creates on request, so a second person can use the system without being handed the admin secret. The kind most small builds skip, and then regret skipping.

Kind 5 — Identifier

Names a resource. Carries no permission at all. These are the values it is safe to paste anywhere, and the ones you can genuinely look up again whenever you want.

A small operator running four serverless services on one cloud account — a marketing site, an internal ops app, a private data API, and a scheduled integration. This is the shape a solo builder or a two-person shop actually ends up with after a year.

Step 1 — Inventory, from the deployed source

Read what each service actually reads at runtime. Documentation drifts; a config file may list bindings that no longer exist; memory is worst of all.

Step 2 & 3 — Classify, then apply the copy test

Two findings the inventory produced

Both are the kind that only surface when you read the source rather than the config.

Replacing a credential is one command. Knowing what breaks is the part that decides whether you do it on a Tuesday morning or at midnight during an outage. This table is the deliverable most teams have never written down.

When rotation is actually warranted

Keep

Delete

Generating without ever seeing it

Every recipe here ends in a pipe, so the value is never printed, never enters shell history, and never touches the clipboard. The examples use a serverless CLI, but the shape is the same for any secret store.

Generate and set, in one breath
openssl rand -base64 32 | tr -d '\n' \
  | your-cli secret put ENCRYPTION_KEY

Nothing displayed. Nothing to copy.
Nothing to paste anywhere by accident.

When you DO need to keep it
T=$(openssl rand -base64 32 | tr -d '=+/' \
    | cut -c1-40)
printf '%s' "$T" | your-cli secret put ADMIN_TOKEN
printf '%s' "$T" | pbcopy

Now it is on the clipboard and nowhere
else. Paste into the password manager,
then copy something else to clear it.

A key copied from a vendor console
K=$(pbpaste | tr -d '[:space:]')
printf %s "$K" | your-cli secret put VENDOR_KEY

The tr strips any stray newline the website
appended. An invisible trailing character is
the single most common reason a freshly-set
key comes back "unauthorized".

Confirm what is set
your-cli secret list

Prints names only, never values. A store
that can show you a secret back is a store
that can leak it — the absence of that
command is a feature.

Is an old value alive? — test, don't guess

Ask the server rather than reasoning about it. Any endpoint that requires authentication and changes nothing will do.

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer PASTE_THE_VALUE" \
  https://your-service.example/api/me

200  → alive. Now: whose is it, and should it still be?
401  → dead. Delete the note; it cannot be revived.

Use a read-only endpoint, and run it in a terminal rather than any tool that logs requests. A value that returns 200 and cannot be attributed to a known holder is itself a reason to rotate.

Where the keepers live

An afternoon's work for a small estate. The output is one table, and the value is almost entirely in step 1 — everything else is mechanical once the list is honest.

The procedure

Commands that do the reading

Every environment read, per service
grep -rhoE "env\.[A-Z][A-Z0-9_]+" src/ | sort -u

Catches the ones no config file mentions.
Also check for destructuring and bracket
access if the codebase uses them:
  grep -rn "} = env" src/
  grep -rn 'env\[' src/

What is actually set
your-cli secret list --name SERVICE

Does the source read anything not set?
Compare the two lists. A name in the source
and missing from the store is either dead
code or a silent fail-open. Both are worth
knowing; only one is urgent.

What the finished artefact looks like

Five columns. Anyone on the team should be able to act from it without asking whoever built the thing.

What the exercise is actually worth

Every concept and command in this codebook. Type to filter; click to jump.

The same four questions, asked of every kind

• A
• API key — what it isKinds
• Audit procedureAudit
• Alive or dead — testing a valueHandling
• B
• Blast radius tableBlast
• Bearer token for a private APIExample
• C
• Client id vs client secretKinds
• Classification — the five kindsKinds
• Constant-time comparisonKinds
• Copy test — keep or deleteHandling
• D
• Delete listHandling
• Discovering env reads with grepAudit
• Duplicates of one nameExample
• E
• Encryption key — the dangerous rotationBlast
• .example file for secret namesHandling
• F
• Fail-open — the silent kindExample
• Five signs you need thisOverview
• G
• Generating a secret safelyHandling
• H
• Hashing — why keys are stored one-wayKinds
• I
• Identifier — not a secretKinds
• Inventory from deployed sourceExample
• K
• Keep ruleHandling
• M
• Method — the four stepsOverview
• Minted key — what it isKinds
• N
• Naming entries in a managerHandling
• O
• OAuth token — what it isKinds
• One name, one live valueOverview
• Output — what the artefact looks likeAudit
• P
• Pipe recipes — never print a secretHandling
• Password managerHandling
• Per-service keys for cost controlKinds
• R
• Rotation — when it's warrantedBlast
• Revoking one user's accessKinds
• S
• Shared secret — what it isKinds
• Scopes — asking for lessKinds
• Shell history riskHandling
• secret list — names, never valuesHandling
• Sequencing a service-to-service rotationBlast
• T
• Trailing whitespace — the 401 causeExample
• Token refresh and expiryKinds
• W
• What the exercise is worthAudit
• When NOT to rotateBlast