Support reverse-proxy trusted header authentication (SSO behind Authelia / Authentik / oauth2-proxy)

[vincenttisseront]

I have searched the existing feature requests, both open and closed, to make sure this is not a duplicate request.

• Yes

The feature

Description
Many Immich deployments sit behind a reverse proxy that already authenticates users (Authelia, Authentik, oauth2-proxy, Keycloak gate, Cloudflare Access, etc.). In that setup, the proxy injects identity headers on every request (for example X-Forwarded-Email, Remote-User, or configurable equivalents).

Today Immich only offers password login and its own OIDC client. Even when the user is already authenticated at the proxy, Immich still shows its login page and requires a second authentication (local password or a full Immich→IdP OAuth round-trip).

This is a common “SSO at the edge” pattern used by many self-hosted apps (e.g. Open WebUI’s WEBUI_AUTH_TRUSTED_* headers). We would like Immich to optionally trust those proxy headers and map them to an Immich user session without a second interactive login.

Why this matters

1. User experience — Users already signed in at the portal/proxy should land in Immich without another click or IdP redirect when the edge has already verified identity.
2. Architecture — When Immich is not exposed directly to the internet and only reachable through an authenticating reverse proxy, duplicating OIDC inside Immich adds complexity (extra client, redirect URIs, callback paths) without adding security for that deployment model.
3. Consistency — Other apps on the same proxy SSO stack can already do header-based login; Immich is the outlier and breaks the “one sign-in for the portal” expectation.
4. Operational fit — Mobile / API access can still use Immich’s native auth; this would be an optional mode for the web UI (and optionally API) when Immich is only reachable via a trusted proxy network.

Proposed behaviour (high level)

• Optional setting, off by default (e.g. TRUSTED_HEADER_AUTH=true or Admin UI toggle).
• Configurable header names, e.g.:
  • email: X-Forwarded-Email (required)
  • display name: X-Forwarded-User (optional)
  • preferred username: X-Forwarded-Preferred-Username (optional)
• When enabled and a trusted email header is present on a request that arrived from the reverse proxy:
  • resolve or auto-provision the Immich user (similar to OAuth auto-register policy);
  • establish a normal Immich session (cookie / JWT as today).
• When the header is missing: keep current behaviour (login page / OAuth).
• Security constraints (must-have):
  • only trust headers from the upstream reverse proxy (private network / known proxy IPs); never trust client-supplied headers on a public listener;
  • document that Immich must not be reachable except through that proxy when this mode is on;
  • optionally require HTTPS and strip/overwrite inbound identity headers at the proxy.

Alternatives considered

• Immich OIDC alone — Works, but still forces a second hop to the IdP (or at least Immich’s OAuth flow) even when the proxy already authenticated the same IdP session. Auto Launch reduces friction but does not remove the duplicate auth stack or callback//auth/login coupling with the proxy.
• External wrappers / custom middleware — Fragile, hard to maintain across Immich upgrades, and not suitable as a supported deployment path.

Related

• Closed draft: #23918
• Discussion: [Feature] Support for Forwarded Headers (Authentication) #22160

We understand maintainers previously preferred OAuth-only. We are opening this to document a concrete reverse-proxy SSO need and to ask whether a narrow, opt-in, proxy-only trusted-header mode could be reconsidered (or whether a documented extension point would be acceptable).

Platform

• Server
• Web
• Mobile

[bo0tzz]

Please don't deliberately open a duplicate thread.

#22160

[vincenttisseront]

I didn't see this one but ok it's deliberately ...

[bo0tzz]

What do you mean you didn't see this one? You literally linked it above...