Application Authentication

Application Authentication deploys a forward-auth proxy that sits in front of your Traefik router. Every request to a protected domain passes through the proxy: unauthenticated users are redirected to your OIDC provider's login page, authenticated sessions are forwarded to the application.

Forward auth applies to Docker/Swarm-routed domains only (applications and compose stacks); Kubernetes ingress is not affected — the toggle has no effect on Kubernetes-deployed applications.

How it works

1. A lightweight auth proxy container is deployed on the target server.
2. Traefik's forwardAuth middleware is added to each domain you protect.
3. Unauthenticated requests are redirected to your OIDC provider.
4. After login, the provider redirects back through the auth domain, and the proxy sets a session cookie.
5. Subsequent requests carry the cookie and are forwarded directly to the application.

Prerequisites

• Enterprise plan with the SSO feature enabled
• An SSO provider configured with OIDC (SAML providers are not supported for application auth)
• A domain for the auth proxy itself (for example, auth.example.com)
• On the cloud plan: a remote server must be selected; local deployment is not available
• The protected domain must share the same base domain as the auth domain — the session cookie is set on the auth domain's base domain, so an auth domain of auth.example.com can only protect domains under example.com (e.g. app.example.com, but not app.other.com)

Deploying the proxy

1. Navigate to Settings → SSO → Application Authentication.
2. Select the target Server (cloud users must choose a remote server).
3. Pick the SSO Provider — only OIDC providers are listed.
4. Enter the Auth Domain — this is the hostname the proxy uses for its own callback (auth.example.com). It must be a valid hostname and must be routed to the same server. Point the domain's DNS A record at the server's IP, as shown in the DNS hint on the page.
5. Click Deploy proxy.

The proxy reads the OIDC issuer, client ID, and client secret directly from the saved SSO provider — they are never exposed in the UI. Under the hood, Skitflow deploys oauth2-proxy as a Docker Swarm service (skitflow-oauth2-proxy-<server>) pinned to a manager node, with a websecure Traefik router and Let's Encrypt certificate for the auth domain.

Protecting a domain

After deployment, open any application or compose stack domain and enable the Protect with SSO toggle. This requires a deployed proxy on the app's server and a domain that shares the proxy's base domain (see Prerequisites). Redeploy the app to apply the change. For applications the config is applied immediately; for compose stacks it takes effect on the next deploy.

Checking proxy status

The proxy status is shown on the Application Authentication settings page. You can also query it directly:

GET /api/trpc/forwardAuth.status?input={"serverId":"<server-id>"}

Returns the Swarm service replica state:

{ "running": true, "replicas": 1 }

Removing the proxy

1. Navigate to Settings → SSO → Application Authentication.
2. Click Remove.

Before the proxy service is removed, Skitflow automatically clears the forwardAuthEnabled flag on every domain that was protected by it, so no application is left pointing at a removed auth endpoint. For applications, Traefik config is re-rendered immediately so the middleware is dropped right away. Compose stack domains lose the middleware on their next deploy.

API reference

All endpoints require an admin session token.

Deploy payload

{
  "serverId": "<server-id-or-null>",
  "ssoProviderId": "<oidc-provider-id>",
  "authDomain": "auth.example.com"
}

Target payload (status / getServerConfig / remove)

{
  "serverId": "<server-id-or-null>"
}

Pass null for serverId to target the local platform server (self-hosted only).