# ADR-006: Programmatic API Key Access Scope

## Status
Accepted

## Date
2026-02-22

## Author
GPUaaS Core Team

## Context
The browser UX is OIDC-first, but platform users also need scriptable access
(CLI/SDK/CI automation) for allocation workflows.

Introducing API keys changes authentication middleware, audit actor modeling,
rate limiting, and API key lifecycle management.

## Decision
- API keys are deferred from v1 implementation scope.
- v1 auth middleware must remain pluggable by introducing a credential
  resolver abstraction so a future API-key resolver can be added without
  handler-level refactors.
- Bearer token handling remains OIDC/JWT-only for v1 public release.

## Consequences
- v1 delivery scope stays focused on OIDC + browser UX.
- Programmatic clients use OIDC-issued tokens until API keys land.
- Future API key rollout requires contract/schema additions, but does not
  require reworking every route handler due to middleware abstraction.

## Follow-up (Phase-2 candidate)
- Add user API key lifecycle endpoints (`list/create/revoke`).
- Store API key hashes only (never plaintext), with `last_used_at` and expiry.
- Extend audit and rate-limit dimensions with key identifier metadata.

## Alternatives Considered
- Build API keys in v1: rejected to avoid delaying core control-plane delivery.
- Hardcode JWT-only auth middleware: rejected due to future extensibility risk.