fix(server): accept x-api-key on /v1/api-keys (close bootstrap footgun post-#34)#35
Merged
khaliqgant merged 1 commit intomainfrom Apr 24, 2026
Merged
Conversation
…nt new ones Pre-purge, /v1/api-keys was HS256-bearer only. After #34 (HS256 purge), the admin-bearer path still exists but now requires a RS256-signed token — meaning operators need the prod RELAYAUTH_SIGNING_KEY_PEM on their laptops to rotate any api-key. Fix: mount apiKeyAuth() on /v1/api-keys{,/*} so an existing api-key scoped relayauth:api-key:manage:* (or * wildcard) can mint, list, and revoke api-keys via x-api-key. This mirrors the pattern already used for /v1/identities and /v1/tokens. Bootstrap: mint one long-lived "operator" api-key once via the existing HS256-bearer flow (before the purge ships to prod). From then on every rotation runs through x-api-key — no prod key material on laptops. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Relayauth#34 purged HS256 but
/v1/api-keysstill only accepts Bearer tokens. Post-purge, that Bearer has to be RS256 — which means any operator rotating an api-key needs the prodRELAYAUTH_SIGNING_KEY_PEMexported locally before callingscripts/mint-api-key.sh. That's prod key material on laptops for a routine operation.What
Mount
apiKeyAuth()on/v1/api-keys{,/*}and swap the three handlers (POST /, GET /, POST /:id/revoke) from the bearer-onlyauthenticateAndAuthorize(...)toauthenticateAndAuthorizeFromContext(c, ...). That helper accepts either a Bearer token or a validated x-api-key (claims pre-populated by the middleware). Same pattern/v1/identitiesand/v1/tokensalready use.Bootstrap procedure
Before the purged server ships to prod:
scripts/mint-api-key.sh(HS256 admin bearer) once to mint a long-lived operator key:*:*:*:*becausevalidateSubsetenforces parent-superset semantics; only the 4-part wildcard can mint keys with any downstream scope.)/v1/api-keyswithx-api-key: $RELAYAUTH_OPERATOR_API_KEY. No more HS256, no prod RSA material needed.What's not touched
validateSubsetscope-escalation check is unchanged — caller's scopes must still be a superset of the new key's.scripts/mint-api-key.sh/generate-dev-token.shstay on RS256 (as chore(server): purge HS256 from relayauth (RS256-only) #34 left them). A follow-up can teach them to speakx-api-key+ an operator key alongside the admin-bearer path if desired.Tests
New:
packages/server/src/__tests__/api-keys-apikey-auth.test.ts— mirrorsidentities-apikey-auth.test.ts, covers mint/list/revoke via x-api-key, insufficient-scope → 403, and revoked-key → 401. All 5 pass. Full server suite: 331 tests, 331 pass.Rollback
Straight revert is safe — restores bearer-only behavior. Any operator keys minted in the meantime remain valid storage-side; they just lose their usable surface until re-applied.