stacklok / toolhive / 35238935410

71%

Build Type

push

github

Committed by web-flow

Commit Message

Add RFC 8628 device authorization grant support (#6647)

* Add device-code storage for RFC 8628 device grant

Headless MCP clients (remote dev hosts, CI-adjacent operator boxes)
cannot complete the browser-based authorization-code callback this
auth server currently requires. RFC 8628 (Device Authorization
Grant) lets such a client obtain a device/user code, hand the user
code to a human for out-of-band verification, and poll for a token
without ever receiving a redirect itself.

This is the storage foundation only, mirroring the existing
PendingAuthorizationStorage shape:

- DeviceRequest/DeviceRequestStatus and the DeviceCodeStorage
  interface (types.go), embedded into Storage alongside
  PendingAuthorizationStorage.
- MemoryStorage and RedisStorage implementations, each keyed by both
  device_code (canonical) and user_code (secondary index), TTL-bound
  via DefaultDeviceRequestTTL.
- ErrInvalidState distinguishes "already authorized/denied" from
  not-found/expired, so a stale verification-page resubmission can
  never clobber a request the token endpoint already consumed.

No HTTP endpoints, token-endpoint grant handler, or config/CRD
surface yet -- those land in follow-up PRs once this storage layer
is in.

Generated with [Claude Code](https://claude.com/claude-code)

* Add device-code grant handler and authorization endpoint

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* Regenerate swagger docs and SDK for device flow config

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* Make Redis device-code storage race-safe and precise

DeleteDeviceRequest and updateDeviceRequest did an unconditional
get-then-write, so two concurrent callers could both observe the
pre-mutation state and both commit: a device_code could be redeemed
twice, or a double-click authorize/deny could silently overwrite the
first transition. Both now run inside a Redis WATCH/MULTI transaction,
mirroring UpsertDCRIssuedClient, so the loser retries against th... (continued)

Coverage Stats

507 of 690 new or added lines in 11 files covered. (73.48%)

5 existing lines in 3 files now uncovered.

82233 of 116276 relevant lines covered (70.72%)

104.29 hits per line