Forward-auth SSO doesn't work on Compose domains

Forward-auth SSO doesn't work on Compose domains

Application Authentication (forward-auth SSO) only works on application domains. Docs already admit it:

Application Authentication is currently only supported on application domains. Docker Compose service domains are not supported.

That's a real gap — most non-trivial deployments are Compose stacks, not a single application. Right now there's no way to put an internal tool or staging service behind SSO without converting it to an application first, which isn't always an option (multi-service stacks, existing compose templates, etc).

Checked open issues/PRs, nothing tracks this yet.

Why it's Application-only today

Not an arbitrary limit — Compose just never got wired into the forward-auth code path, because the two domain types route completely differently:

• Application: dedicated per-app dynamic Traefik config file (traefik/domain.ts → manageDomain). Forward-auth middleware is written to the shared middlewares.yml and referenced from there (traefik/forward-auth.ts → createForwardAuthMiddleware).
• Compose: no per-service config file — routing is pure Docker labels on the target service inside docker-compose.yml (docker/domain.ts → addDomainToCompose / createDomainLabels).

And the access/enable code hard-rejects anything without an applicationId:

// packages/server/src/services/proprietary/forward-auth.ts:305-335
const resolveApplicationDomain = async (domainId: string) => {
  const domain = await findDomainById(domainId);
  if (!domain.applicationId) {
    throw new TRPCError({ code: "BAD_REQUEST", message: "..." });
  }
  ...
};

Same guard in assertApplicationDomainAccess. And the UI toggle (HandleForwardAuth) is only rendered on the Application domain screen — the Compose one doesn't have it at all.

Proposed fix

The middleware itself doesn't need to change — it already lives in a shared, app-agnostic middlewares.yml. Just need a second way to attach it and a second way to authorize it:

1. Add a Compose counterpart to resolveApplicationDomain / assertApplicationDomainAccess that resolves via domain.composeId instead, using checkServicePermissionAndAccess against the compose.
2. In createDomainLabels (docker/domain.ts), emit traefik.http.routers.<router>.middlewares=...,forward-auth-<name>@file when domain.forwardAuthEnabled.
3. Widen forwardAuthMiddlewareName to include serviceName, not just appName — one Compose stack can have several services with independent domains, names must not collide.
4. Add the HandleForwardAuth toggle to the Compose domain UI.
5. Check isolatedDeployment/randomize don't drift the middleware name between redeploys of the same domain.

Alternatives considered

• Convert the service to an application — not always possible.
• Custom Traefik basic-auth middleware in front — works today, but it's a shared password, not real SSO/OIDC identity.

Context

• Forward-auth SSO landed in #4555, merged 2026-06-06 (closed #123). The Application-only limit was part of the original design, not a regression.
• Related but not duplicate: #4284, #4408, #4415.

Start with packages/server/src/services/proprietary/forward-auth.ts and the referenced traefik/domain.ts and docker/domain.ts paths, then inspect the Application domain UI containing HandleForwardAuth. Trace current authorization, label generation, and middleware naming before checking related tests or deployment flows. Done means Compose domains expose the toggle, authorize correctly, attach the existing forward-auth middleware, and retain stable names across redeploys.