Feature request: trusted reverse-proxy / SSO mode for dashboard auth

[cometto2007]

Summary

Please add a supported trusted reverse-proxy / SSO auth mode for the onWatch dashboard, so deployments already protected by Authentik, Authelia, oauth2-proxy, Traefik ForwardAuth, etc. do not require a second onWatch login.

Problem

In Docker or homelab deployments, onWatch is often exposed only through a reverse proxy that already performs authentication. For example:

1. User opens https://onwatch.example.com
2. Reverse proxy forwards through an SSO provider such as Authentik
3. onWatch then still shows its own local login form

That double-login is secure, but awkward. It also makes onWatch feel less native in existing SSO-protected internal dashboards.

At the same time, simply disabling onWatch auth entirely would not be a good fit, because internal Docker callers may still reach http://onwatch:9211 directly on a Docker network.

Proposed Solution

Add an auth mode such as:

ONWATCH_AUTH_MODE=local          # default/current behavior
ONWATCH_AUTH_MODE=trusted_proxy  # trust identity headers from configured proxies

In trusted_proxy mode:

• Browser/dashboard routes skip the onWatch login when the request comes from a trusted proxy and contains a valid authenticated-user header.
• API routes keep the existing Basic Auth/session behavior, or optionally support a separate service token.
• The current local login remains the default and continues to work for simple localhost installs.

Suggested config shape:

ONWATCH_AUTH_MODE=trusted_proxy
ONWATCH_TRUSTED_PROXY_CIDRS=172.30.0.0/16,127.0.0.1/32
ONWATCH_TRUSTED_USER_HEADER=X-authentik-username
ONWATCH_TRUSTED_EMAIL_HEADER=X-authentik-email
ONWATCH_TRUSTED_NAME_HEADER=X-authentik-name

The header names should be configurable so this works with Authentik, Authelia, oauth2-proxy, Traefik ForwardAuth, Caddy forward_auth, Nginx auth_request, etc.

Security Considerations

Important safeguards:

• Default stays local.
• Trusted headers are accepted only from configured proxy CIDRs or exact proxy IPs.
• Direct requests that spoof trusted headers are rejected or ignored.
• If trusted_proxy is enabled without trusted proxy configuration, fail closed.
• API access remains separately protected, since internal service-to-service callers may bypass the public reverse proxy.

Why trusted proxy instead of full OIDC?

Full OIDC would also solve this, but trusted proxy mode is simpler and fits many self-hosted deployments where identity is already centralized at the ingress layer. It would avoid each small dashboard app needing to implement its own OIDC flow.

Acceptance Criteria

• Existing behavior remains unchanged by default.
• With trusted proxy mode enabled, an authenticated reverse-proxy request reaches the dashboard without showing the onWatch login page.
• Unauthenticated or direct requests do not bypass auth.
• /api/* remains protected for scripts/internal containers.
• Documentation includes examples for a common forward-auth setup.