migration(rs256): phase 119 — Implement /v1/api-keys + x-api-key middleware#20
Merged
migration(rs256): phase 119 — Implement /v1/api-keys + x-api-key middleware#20
Conversation
…leware Generated by workflows/119-*.ts via scripts/run-rs256-migration.sh. Spec: specs/api-keys-and-rs256-migration.md (phase 119). Co-Authored-By: agent-relay <agent@agent-relay.com>
- Mount apiKeyAuth() on /v1/identities/* (wildcard) and /v1/tokens/* so PATCH/DELETE/suspend/retire/reactivate accept x-api-key. - Global auth gate admits x-api-key as an alternate credential when the middleware has authenticated the request. - Enforce scopes ⊆ caller.scopes on POST /v1/api-keys to prevent privilege escalation via caller-supplied scope arrays. - Regression tests for every identity sub-path via x-api-key, plus scope-subset enforcement and legitimate-subset cases. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The previous gate admitted any request carrying a non-empty x-api-key header, relying on per-route handlers to validate. That's a footgun: a future route added without mounting apiKeyAuth() would silently accept unvalidated keys. apiKeyAuth() already rewrites Authorization into a synthesized Bearer on valid-key success, so every path that accepts x-api-key already reaches the gate with Authorization set. The gate now only checks for Authorization — no raw-x-api-key escape hatch. Regression test: request with only x-api-key to a path that doesn't mount apiKeyAuth() must return 401 missing_authorization. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
kjgbot
force-pushed
the
migration/rs256/119-api-keys
branch
from
2cc9a69 to
184cdb9
Compare
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
1 participant
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.
Phase 119 — Implement /v1/api-keys + x-api-key middleware
Part of the api-keys + RS256 migration. See
specs/api-keys-and-rs256-migration.mdfor the full design.Generated by
workflows/119-*.tsand committed byscripts/run-rs256-migration.sh. Every workflow runs the strict review template (implementer self-review + 2 parallel specialist peer reviewers + architect synthesis + approval gate); this PR exists because the gate passed.Run order in the migration
This PR is phase 119. Merge in order; each phase assumes its predecessors are deployed.
Review focus
The workflow already enforced security + spec/compat review. Human review here should focus on: