Forward-auth SSO doesn't work on Compose domains

Open
  • Is something wrong?
#5,461 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
65/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
docker, typescript
Domain
authentication, devops, frontend

Research direction

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.

Written by the indexing model from the issue text.

Description

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.
Dominant language
TypeScript
Stars
38.2k
Forks
3.1k
Avg merge
2d 11h
Merged PRs (30d)
65

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Dokploy/dokploy

All issues in Dokploy/dokploy

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.