Skip to content

feat(auth): verify OIDC access tokens for the API - #161

Draft
djwhitt wants to merge 9 commits into
oidc-provider-configfrom
oidc-api-tokens
Draft

feat(auth): verify OIDC access tokens for the API#161
djwhitt wants to merge 9 commits into
oidc-provider-configfrom
oidc-api-tokens

Conversation

@djwhitt

@djwhitt djwhitt commented Aug 15, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • strictly verify API bearer JWT signatures and protected headers against the supervised JWKS cache
  • enforce exact issuer/audience, subject, time, token type/use, key strength, curve, and algorithm rules
  • bound unknown-key refreshes with provider-wide cooldown and single-flight behavior
  • normalize only exact configured claims into principals and capabilities before API parsing
  • reject browser client IDs in API token audiences while preserving azp/client_id metadata
  • require either the browser client boundary or an API-specific token type/required-claim profile before API startup

Tracker: T-232

Validation

  • ../bin/x mix ci
  • ../bin/test
  • ../bin/x mix dialyzer
  • focused crypto and token-adversary reviews

Stack

Depends on #160. This is layer 4 of stack #151.

Stack managed with GitHub Stacks CLI.

Authenticate bounded JWT bearer tokens with strict asymmetric JOSE verification, exact issuer and audience checks, integer time claims, supervised JWKS rotation, and exact claim-value capability mapping. Unknown key refreshes are globally rate-limited and failures remain generic and fail closed.

A temporary coarse gate requires all current API capabilities until T-233 adds route-specific authorization.
@djwhitt djwhitt changed the title oidc api tokens feat(auth): verify OIDC access tokens for the API Aug 15, 2026
@djwhitt
djwhitt marked this pull request as draft August 16, 2026 00:09
Carry the hardened provider cache, updated lower stack, and current origin/main into the published API-token layer without rewriting existing commits.
T-232 adds role-specific token type and required-claim policies, rejects an API audience that aliases the browser client id, and keeps the global settings only as backward-compatible defaults.
Carry the provider follow-up validation and refresh-worker lifecycle fix into the published API-token layer without rewriting its existing commits.
Propagate the provider-layer callback, host, and scope validation through the published API-token layer without rewriting existing commits.

Tests: ../bin/x mix ci
Tests: ../bin/test
Tests: ../bin/x mix dialyzer
Reject API bearer tokens whose audience list contains the configured browser client ID, while preserving authorized-party metadata on legitimate resource access tokens. Cover the signed multi-audience ID-token confusion case and document the deployment binding.

Tests: ../bin/test test/smolquery/auth/oidc/token_test.exs

Refs T-232 and PL-27.
Refuse API OIDC startup unless the deployment supplies either the browser client ID to exclude from audiences or an API-specific token type/required-claim profile. Split API/web deployments can no longer silently fall back to audience-only ID-token acceptance.

Refs T-232 and PL-27.
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