Skip to content

feat(management): let an API key look up its own project - #327

Open
IamKirbki wants to merge 1 commit into
mainfrom
feat/management-api-key-identity
Open

IamKirbki wants to merge 1 commit into
mainfrom
feat/management-api-key-identity

Conversation

@IamKirbki

Copy link
Copy Markdown
Contributor

Why

A caller that holds only an API key can't find out which project the key belongs to:

  • Every project-scoped management route needs {projectID} in the URL.
  • Every route without a project (whoami, profile, projects, …) is admin-only and returns "this endpoint is only available to admins".
  • A request to the wrong project gets a generic 401 with no hint about the right one. That's on purpose and should stay.

Right now the only way to get the project ID is to copy it out of the console URL.

What

A new endpoint, GET /api/admin/auth/key, which returns id, name, project_id, organization_id and role.

  • Only API keys can call it. Admins and any other caller get a 403.
  • No permission check beyond authentication. The key only learns about itself, i.e. the one project it can already act on.
  • The role comes from the auth method row, because rbac.Actor doesn't carry it. The lookup is scoped to the key's own project. A key revoked after the auth cache was filled gets a 404 instead of stale data.

Changes

  • resources.yml: new path plus a CurrentAPIKey schema
  • resources_gen.go and console/src/oapi/management.generated.ts: regenerated (additive only)
  • AuthMethodsController.GetCurrentAPIKey and handler tests for: API key, admin refused, revoked key

Testing

go test ./internal/http/controllers/v1/management/ -run TestGetCurrentAPIKeyHandler passes against a real Postgres (testcontainers).

Add GET /api/admin/auth/key, which returns the calling API key's id, name,
project, organization and role. Every other management endpoint either
names the project in its URL or is reserved for admins, so a caller
holding only a key had no way to discover which project to address.

The key learns only about itself, so no permission check is needed beyond
authentication. Admins and other actors are refused with a 403. The role
is read back from the auth method rather than the actor, which does not
carry it; a key revoked since the auth cache was filled gets a 404.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant