Product4 min read
API tokens: one environment, read-only, always expiring
Your app reads its secrets at start-up with a token that can't do anything else. No .env file to leak.
An app needs its secrets when it starts. Until now, that meant a .env file on the server, in the CI settings and on every developer's laptop. With Nionx, the app asks for them instead, with an API token.
What a token can do
As little as possible, on purpose:
- One environment. A token for Production of one project reads that environment and nothing else.
- Read-only. It can't create, change or delete anything.
- Always expires. After 7, 30, 90 or 365 days. There's no “never”.
- Shown once. We only keep a fingerprint (a SHA-256 hash), so not even Nionx can show it again.
- Revocable. Revoke it and it stops working on the next request.
Using it
curl https://api.nionx.cloud/v1/secrets \
-H "Authorization: Bearer $NIONX_TOKEN"You get every configured secret of that environment as JSON, or as KEY="value" lines with ?format=env, so you can load them into a shell without writing a file:
set -a
source <(curl -fsS "https://api.nionx.cloud/v1/secrets?format=env" \
-H "Authorization: Bearer $NIONX_TOKEN")
set +aGuard rails
Only admins and owners can create tokens, and they confirm their password first. Every read is recorded in the audit log with the token's name and how many values it read (never the values). The API answers only to tokens: a browser session can't read values, and a token can't use the dashboard.
