feat(webapp): consolidate auth path + add comprehensive auth tests

[matt-aitken]

Summary

Consolidates the webapp's authentication and authorization into a small set of route helpers, replacing the ad-hoc requireUser / requireUserId / authenticatedEnvironmentForAuthentication calls scattered across routes. Same security model, but the per-request flow (authenticate → authorize → load) now lives in one place per route family.

Adds a comprehensive end-to-end auth test suite that didn't exist before — 162 tests covering API key, PAT and JWT auth across the public API surface, plus dashboard session auth for admin pages.

Changes

Dashboard auth (started, partial rollout)

Admin and settings pages migrated to a unified loader/action helper that authenticates the session, runs an authorization check, and exposes the result to the route. Other dashboard routes still on the old pattern; remaining migration tracked separately.

Migrated routes:

• admin.* (14 admin / back-office / feature-flags / LLM-models / notifications / orgs / concurrency pages)
• _app.orgs.$organizationSlug.settings.team
• _app.orgs.$organizationSlug.settings.roles

API / realtime / engine auth (complete for the migrated families)

71 routes migrated to a unified apiBuilder that centralizes Bearer / PAT / Public-JWT authentication and applies the per-route authorization check before the handler runs. Includes:

• api.v1.* and api.v2.* and api.v3.* — tasks, runs, batches, queues, prompts, deployments, query, sessions, waitpoints, packets, workers, idempotency keys
• realtime.v1.* — runs, batches, sessions, streams
• engine.v1.* — dev / worker-action protocols

Side effect: action aliases preserved historic JWT scope semantics where the new model is stricter (e.g. a write:tasks JWT now also satisfies trigger / batchTrigger / update actions on the same resource — matched at the auth boundary, not in the route handler).

Auth test suite (new — *.e2e.full.test.ts)

162 e2e tests run against a real spawned webapp + Postgres (no mocks). Coverage matrix:

• API key auth — read / write / trigger / batchTrigger / deploy actions across runs, batches, deployments, prompts, queues, query, sessions, input-streams, waitpoints, tasks, idempotency keys; multi-key resources (a run carries batch / tag / task identifiers — auth must accept any matching scope)
• Personal Access Token auth — comprehensive matrix: scope match, scope mismatch, missing scope, expired token, malformed token
• Public JWT auth — sub-vs-URL environment resolution, expired JWTs, signature verification, scope checking, otu (one-time-use) token semantics, branch-environment signing-key fallback
• Dashboard session auth — admin-only pages reject non-admins; per-action gating
• Cross-cutting edge cases — revoked API key grace window, JWT cross-environment isolation, MissingResource branch behaviour

Test plan

• pnpm run typecheck --filter webapp clean
• pnpm exec vitest run --config apps/webapp/vitest.e2e.full.config.ts — 162/162 pass
• Spot-check an authed API endpoint with a valid + invalid API key against a local stack
• Spot-check the migrated admin pages render and gate non-admins

[changeset-bot]

🦋 Changeset detected

Latest commit: 5063f84

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 31 packages

Name	Type
@trigger.dev/plugins	Patch
@trigger.dev/rbac	Patch
@trigger.dev/build	Patch
@trigger.dev/core	Patch
@trigger.dev/python	Patch
@trigger.dev/react-hooks	Patch
@trigger.dev/redis-worker	Patch
@trigger.dev/rsc	Patch
@trigger.dev/schema-to-json	Patch
@trigger.dev/sdk	Patch
@trigger.dev/database	Patch
@trigger.dev/otlp-importer	Patch
trigger.dev	Patch
d3-chat	Patch
references-d3-openai-agents	Patch
@internal/cache	Patch
@internal/clickhouse	Patch
@internal/llm-model-catalog	Patch
@internal/redis	Patch
@internal/replication	Patch
@internal/run-engine	Patch
@internal/schedule-engine	Patch
@internal/testcontainers	Patch
@internal/tracing	Patch
@internal/tsql	Patch
@internal/zod-worker	Patch
references-nextjs-realtime	Patch
references-realtime-hooks-test	Patch
references-realtime-streams	Patch
@internal/sdk-compat-tests	Patch
references-telemetry	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

Walkthrough

Adds a new RBAC system and plugin surface: a @trigger.dev/rbac package, RBAC contracts in packages/plugins, a lazy plugin loader and fallback controller, and a server-side rbac service. Introduces dashboard/api route builder abstractions that centralize authentication/authorization, updates many API/dashboard routes to use typed { type, id } resources (removing prior superScopes), and adds everyResource/authorization aliasing. Webapp changes include role UI (organization Roles page, role picker, token role assignment), invite RBAC handling, schema/migration for OrgMemberInvite.rbacRoleId, project-created environment provisioning refactor, extensive e2e RBAC tests and shared test-server infrastructure, and a CI workflow for full E2E auth runs.

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~120 minutes

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch rbac-packages

[devin-ai-integration]

Devin Review found 4 new potential issues.

View 9 additional findings in Devin Review.

[devin-ai-integration]

🟡 authenticateRequestForApiBuilder hardcodes HTTP 401, discarding a potential 403 from the RBAC layer

The authenticateRequestForApiBuilder bridge function at apiBuilder.server.ts:61 always returns status: 401 when the RBAC result is ok: false, even though BearerAuthResult (defined in packages/plugins/src/rbac.ts:96) allows status: 401 | 403. The return type is explicitly narrowed to status: 401 at line 56. A plugin's authenticateBearer could legitimately return 403 for cases like a suspended account or IP-blocked request — the wrapper silently converts that to 401, which is semantically wrong (401 = "who are you?" vs 403 = "you're not allowed") and would confuse debugging and client retry logic.

Suggested change

	| { ok: false; status: 401; error: string }
	| { ok: true; authentication: ApiAuthenticationResultSuccess; ability: RbacAbility }
	> {
	const result = await rbac.authenticateBearer(request, { allowJWT });
	if (!result.ok) {
	return { ok: false, status: 401, error: result.error };
	| { ok: false; status: 401 | 403; error: string }
	| { ok: true; authentication: ApiAuthenticationResultSuccess; ability: RbacAbility }
	> {
	const result = await rbac.authenticateBearer(request, { allowJWT });
	if (!result.ok) {
	return { ok: false, status: result.status, error: result.error };

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔴 buildJwtAbility treats any admin:TYPE scope as a universal wildcard, broadening access beyond old behavior

In ability.ts:30, the JWT ability builder checks scopeAction === "admin" and immediately returns true for any action/resource. Because the scope is split on :, a scope like admin:sessions produces scopeAction = "admin" — making it equivalent to the bare admin scope (universal access). In the old checkAuthorization system (authorization.server.ts:74-78), admin:sessions was treated as an opaque superScope string that only matched routes explicitly listing it, so a JWT with scope admin:sessions could NOT access routes with superScopes: ["read:runs", "admin"]. Post-migration, that same JWT passes auth on every route. While the practical likelihood of a customer minting JWTs with admin:TYPE scopes (rather than plain admin) is low, this is a silent privilege escalation for any such tokens.

Example of the behavioral difference

Old: JWT {scopes: ["admin:sessions"]} on GET /api/v1/runs → superScopes ["read:runs","read:all","admin"] → "admin:sessions" not in superScopes → denied (403)

New: same JWT → buildJwtAbility(["admin:sessions"]) → scopeAction === "admin" → returns true → authorized

Prompt for agents

The `buildJwtAbility` function in internal-packages/rbac/src/ability.ts splits scopes on `:` and checks whether `scopeAction === "admin"` at line 30, returning true unconditionally. This means any scope starting with `admin:` (e.g. `admin:sessions`, `admin:tasks`) is treated as a universal wildcard, equivalent to plain `admin`. This is broader than the old superScopes behavior where `admin:sessions` only matched routes that explicitly listed it.

To fix: the `admin` wildcard check should only fire when the scope is exactly the string `admin` (single segment, no type/id parts). When the scope has additional segments like `admin:sessions`, it should be treated like a normal scope where `admin` is the action and `sessions` is the type — i.e., it grants `admin` action on `sessions`-type resources only. One approach: check `if (scopeAction === "admin" && !scopeType) return true;` to limit the wildcard to plain `admin`. Then let the normal type/id matching logic handle `admin:sessions` as action=admin, type=sessions.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 everyResource([]) is a vacuous-truth authorization bypass

In apiBuilder.server.ts:160-161, checkAuth delegates to resource.resources.every(...). JavaScript's Array.prototype.every returns true for empty arrays (vacuous truth). This means everyResource([]) passes auth for ANY JWT, even one with zero scopes. The batch trigger routes (api.v1.tasks.batch.ts, api.v2.tasks.batch.ts) build the everyResource array from body.items, so an empty items array produces everyResource([]). In practice this isn't exploitable because: (1) body parsing happens before auth in createActionApiRoute, and the Zod schema may reject empty arrays; (2) even if auth passes, the handler explicitly returns 400 for empty batches. However, the auth layer "leaking" a 400 instead of 403 for empty batches is a minor information disclosure (confirms the route exists and accepts batches). Consider adding a guard: if (resource.resources.length === 0) return false;.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 Fallback controller does not check branch-name resolution for API keys

The original findEnvironmentByApiKey in models/runtimeEnvironment.server.ts accepts a branchName parameter and resolves branch environments via childEnvironments includes. The new fallback's authenticateBearer (internal-packages/rbac/src/fallback.ts:88-91) looks up the environment by apiKey alone without branch resolution. However, this is mitigated because authenticateRequestForApiBuilder at apiBuilder.server.ts:67 calls findEnvironmentById(result.environment.id) which loads the full environment shape but also doesn't resolve branches. Branch resolution was handled by the old authenticateApiKey function via the x-trigger-branch header, and this PR doesn't change the header extraction. Worth verifying that branch-based routing still works end-to-end if it's used.

---

Was this helpful? React with 👍 or 👎 to provide feedback.