feat: add workspace admin API foundations

[ben-fornefeld]

Summary

This PR lays the groundwork for the Workspaces & Projects v1 admin surface and restructures the shared auth package behind a stable public facade.

• Adds the dashboard-api /admin/v1 OpenAPI surface and generated handlers for workspace administration.
• Adds AdminJWTAuth for short-lived service JWTs configured through ADMIN_AUTH_PROVIDER_CONFIG.
• Keeps the consumer API under packages/auth/pkg/auth while moving implementation into focused Go internal packages.
• Shares one ProviderConfig shape between AUTH_PROVIDER_CONFIG and ADMIN_AUTH_PROVIDER_CONFIG.

Motivation

The dashboard-api needs to verify service-to-service JWTs for workspace admin endpoints, while the API already verifies auth-provider tokens. Both flows need shared configuration and JWKS validation without exposing implementation packages or forcing consumers to import token internals.

The public auth package is now a facade, so callers continue using APIs such as auth.NewAuthService, auth.NewAdminVerifier, and the existing middleware constructors while implementation details remain protected by Go's internal boundary.

Changes

Auth package

• Keeps packages/auth/pkg/auth as the stable consumer-facing facade.
• Moves implementation into internal/authcontext, internal/middleware, internal/service, internal/team, internal/token, internal/token/jwks, and internal/token/oidc.
• Re-exports the supported configuration, verifier, service, middleware, team-policy, context, error, and testing APIs through auth.
• Prevents consumers from importing token, JWKS, OIDC, cache, store, and middleware internals directly.

JWT and JWKS verification

• Adds auth.NewAdminVerifier for multi-issuer admin service JWT verification.
• Loads admin keys directly from each issuer's /.well-known/jwks.json endpoint.
• Requires every signing JWK to declare alg and derives accepted JWT signing methods from current JWKS storage.
• Refreshes the valid-method allowlist together with JWKS key refreshes, allowing algorithm rotations without restarting the service.
• Preserves OIDC discovery and identity resolution for auth-provider user tokens.

Configuration

• AUTH_PROVIDER_CONFIG configures user auth-provider JWTs.
• ADMIN_AUTH_PROVIDER_CONFIG configures admin service JWTs using the same ProviderConfig JSON shape.
• Dashboard-api fails fast on invalid configured issuers and rejects AdminJWTAuth requests when no admin provider is configured.

Dashboard API

• Adds the workspace-agnostic /admin/v1 OpenAPI operations and AdminJWTAuth security scheme.
• Registers API-key and service-JWT admin authenticators through the public auth facade.
• Keeps existing auth-provider bearer and team authentication flows unchanged.

Usage example

{
  "jwt": [
    {
      "issuer": {
        "url": "https://workspace-api.example.com",
        "audiences": ["e2b-dashboard-api"]
      },
      "cacheDuration": "5m"
    }
  ]
}

Set this JSON as ADMIN_AUTH_PROVIDER_CONFIG for admin service JWTs or as AUTH_PROVIDER_CONFIG for auth-provider JWTs.

Testing

• go test ./packages/auth/...
• go test ./packages/api/internal/cfg/...
• go test ./packages/dashboard-api/...
• golangci-lint run ./packages/auth/... ./packages/api/... ./packages/dashboard-api/...
• go build ./packages/api/... ./packages/dashboard-api/...

[cursor]

PR Summary

Medium Risk
Touches authentication middleware and JWT/JWKS validation paths used at request time; misconfiguration or verifier bugs could deny admin traffic or weaken token checks, though behavior is covered by tests and unimplemented handlers limit data-plane impact.

Overview
Introduces workspace control-plane admin routes on the dashboard API secured by AdminJWTAuth, backed by a new ADMIN_AUTH_PROVIDER_CONFIG that reuses the same JSON shape as user auth-provider JWT settings. Shared auth is reorganized behind the public auth facade with implementation in internal packages, while JWT verification is split so admin service tokens validate via issuer /.well-known/jwks.json, require each JWK to declare alg, and refresh allowed signing methods with JWKS rotation; user OIDC tokens still use discovery plus identity lookup. The new /admin/v1 operations are wired in OpenAPI and routing but currently respond with 501 Not Implemented.

^{Reviewed by Cursor Bugbot for commit b1f4a77. Bugbot is set up for automated code reviews on this repo. Configure here.}

[codecov]

Codecov Report

❌ Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
packages/api/internal/cfg/model.go	0.00%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[gemini-code-assist]

Code Review

This pull request introduces the AdminJWTAuth security scheme to secure workspace-agnostic /admin/v1 operations in the dashboard API. It refactors the authentication package by separating generic JWKS token verification into a new jwks package and OIDC-specific identity lookup into an oidc package. Additionally, it defines the new admin endpoints in the OpenAPI specification, registers the corresponding middleware, and adds placeholder handlers. Feedback is provided to add a defensive nil check in the OIDC verifier's Verify method to prevent potential nil pointer dereferences.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[claude]

No bugs found, but I'd recommend a human review given this touches auth/JWT verification code and introduces a new admin API surface.

Extended reasoning...

Overview

This PR does two things: (1) extracts JWT/OIDC verification code from packages/auth/pkg/auth into a new packages/auth/pkg/token package (with jwks and oidc sub-packages), shared between api and dashboard-api; and (2) adds a new /admin/v1 OpenAPI surface to dashboard-api for workspace/project control-plane administration, authenticated via a new AdminJWTAuth scheme backed by token.AdminVerifier (multi-issuer EdDSA service JWTs). All six new admin handlers are stubbed to return 501 Not Implemented, so no real admin logic ships yet.

Security risks

This is squarely auth-adjacent code: JWT signature verification, audience validation, and a new bearer-auth scheme protecting future workspace-admin write operations (project upsert/delete, membership, limits, user purge). The refactor itself appears to preserve behavior (the old Verifier.Verify logic was split into a claims-only jwks.Verifier plus an OIDC identity-resolution wrapper, and tests were moved/updated accordingly), and AdminVerifier correctly restricts to EdDSA and forces expiration/leeway. Since the concrete handlers are all not-implemented stubs, there's no immediate authz-bypass surface live yet, but the shape of AdminJWTAuth (accepting any of a list of configured issuers, verified but with no further scoping shown in this PR) is worth a human's attention before real handler logic lands on top of it.

Level of scrutiny

Given this touches shared authentication/verification code used by both api and dashboard-api, and lands the auth scheme for a new administrative API, I'd apply high scrutiny — this is exactly the kind of change (auth, JWT handling) called out as warranting human review rather than automated approval, even though the bug-hunting pass found nothing and the moved code is well covered by existing/updated unit tests.

Other factors

No CODEOWNERS conflicts were surfaced, and the diff is large (28 files) mixing a mechanical rename/move with genuinely new security-relevant surface (new security scheme, new config env var ADMIN_AUTH_CONFIG). The bug-hunting system found no issues, and one candidate doc-consistency concern in ARCHITECTURE.md was already investigated and ruled out. Test coverage for the moved/new verifier code looks solid (audience matching, expiry, wrong-signing-method rejection, disabled-config nil-verifier handling).

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b1f4a77. Configure here.}