[BUG] SSO redirect_uri uses http behind HTTPS reverse proxy

[adrianmusante]

Prerequisites

• I have read the troubleshooting guide

Rclone Pre-flight Checklist (if applicable)

• This issue is NOT related to rclone (skip if not using rclone)
• I have tested rclone listremotes and rclone lsd remote: on the host and they work
• I have verified the rclone config is mounted into the container
• I have restarted the container after config changes

Bug Description

When Zerobyte runs behind an HTTPS reverse proxy that terminates TLS and forwards to the container over plain HTTP (typical Nginx / Nginx Proxy Manager setup), SSO/OIDC sign-in builds an OAuth redirect_uri with the http:// scheme even though:

• BASE_URL is set to https://…
• The proxy sends X-Forwarded-Proto: https (and X-Forwarded-Scheme: https)
• TRUST_PROXY=true

Authentik (and most IdPs) only allow the HTTPS callback, so login fails with an invalid redirect URI.

Root cause appears to be better-auth config in app/server/lib/auth.ts:

• baseURL.protocol is "auto"
• advanced.trustedProxyHeaders is not set

Per better-auth docs, with protocol: "auto", X-Forwarded-Proto is only honored when advanced.trustedProxyHeaders: true. Otherwise the request URL scheme is used — which is http on the internal Docker network. TRUST_PROXY only affects X-Forwarded-For for rate limiting / IP handling; it does not enable trusted proxy headers for better-auth URL construction. BASE_URL is only used as a fallback, not for the live redirect_uri.

Steps to Reproduce

1. Deploy Zerobyte v0.43.0 with Docker Compose behind a reverse proxy that terminates TLS and proxies to http://zerobyte:4096.

2. Set env:

   • BASE_URL=https://zerobyte.example.com
   • TRUST_PROXY=true
   • TRUSTED_ORIGINS=https://zerobyte.example.com,https://auth.example.com

3. Ensure the proxy sets Host, X-Forwarded-For, and X-Forwarded-Proto: https (NPM/nginx stock config does this).

4. Configure an OIDC SSO provider (e.g. Authentik) with callback
   https://zerobyte.example.com/api/auth/sso/callback/<providerId> only.

5. Start SSO sign-in, e.g.:

   curl -s -X POST 'https://zerobyte.example.com/api/auth/sign-in/sso' \
     -H 'Content-Type: application/json' \
     -d '{"providerId":"<providerId>","callbackURL":"/"}'

6. Inspect the returned url → query param redirect_uri.

Expected Behavior

redirect_uri should use HTTPS, matching the public URL / BASE_URL scheme, e.g.:

redirect_uri=https://zerobyte.example.com/api/auth/sso/callback/<providerId>

One possible approach (happy to defer to maintainers): honor X-Forwarded-Proto when behind a reverse proxy (e.g. advanced.trustedProxyHeaders: true alongside TRUST_PROXY=true), or derive better-auth protocol from the scheme of BASE_URL instead of "auto".

Zerobyte version / commit

v0.43.0

Deployment Method

Docker Compose

Backup/Repository Context

N/A (SSO / auth only)

Logs / Error Messages

Response from POST /api/auth/sign-in/sso (sanitized; client_id / state / PKCE redacted):

{
  "url": "https://auth.example.com/application/o/authorize/?response_type=code&client_id=REDACTED&state=REDACTED&scope=openid+email+profile&redirect_uri=http%3A%2F%2Fzerobyte.example.com%2Fapi%2Fauth%2Fsso%2Fcallback%2Fauthentik&code_challenge_method=S256&code_challenge=REDACTED",
  "redirect": true
}

Decoded redirect_uri:

http://zerobyte.example.com/api/auth/sso/callback/authentik

Proxy headers on the same NPM stack (checked with a whoami-style upstream) include X-Forwarded-Proto: https. Sending that header explicitly to Zerobyte still produces http in redirect_uri.

Relevant config from upstream source:

baseURL: {
  allowedHosts: config.allowedHosts,
  protocol: "auto",
  fallback: config.baseUrl,
},
advanced: {
  cookiePrefix: "zerobyte",
  useSecureCookies: config.isSecure,
  // trustedProxyHeaders not set
  ipAddress: { ... },
},

IdP error (Authentik): redirect URI mismatch, only the HTTPS callback is registered.

[lyallcooper]

I’m also running into this same issue starting with v0.43.0

[janreinhardt]

Can confirm this is a regression, verified by downgrade test: with the exact same Traefik/reverse-proxy setup, BASE_URL and TRUSTED_ORIGINS config, OIDC login (PocketID in my case) works correctly on v0.42.0 and fails on v0.43.0 with:

The redirect_uri 'http://zerobyte./api/auth/sso/callback/OIDC' is not registered for this client.

Nothing else changed besides the image tag. This narrows it down to something between v0.42.0 and v0.43.0 rather than a general BASE_URL/trustedProxyHeaders gap that would affect all versions equally.

[nicotsx]

Thanks for reporting, better-auth did release some changes regarding this. I'm working on a fix

[nicotsx]

Can someone please test with version v0.43.1-beta.2 and let me know if it resolves the issue?

[lyallcooper]

Can someone please test with version v0.43.1-beta.2 and let me know if it resolves the issue?

Yep seems to work for me!

[adrianmusante]

Can someone please test with version v0.43.1-beta.2 and let me know if it resolves the issue?

Works correctly for me too. Thanks for the quick fix.

[janreinhardt]

Does not work with my PocketID.
Zerobyte logging: ERROR [Better Auth]: JWTClaimValidationFailed: unexpected "iss" claim value
PocketID: standard logging, no errors

= is this on me and my OIDC settings / values?

[nicotsx]

Thanks for testing @lyallcooper I have release v0.43.1 with the fix

@janreinhardt could you send me:

1. The Issuer URL saved in Zerobyte’s SSO provider settings.
2. The issuer value shown at https://YOUR-POCKET-ID-DOMAIN/.well-known/openid-configuration

[janreinhardt]

@nicotsx

1. is https://raspi5.xxyyzz.ts.net/
2. {"authorization_endpoint":"https://raspi5.XXYYZZ.ts.net/authorize","authorization_response_iss_parameter_supported":true,"claims_supported":["sub","given_name","family_name","name","display_name","email","email_verified","preferred_username","picture","groups","auth_time","amr"],"client_id_metadata_document_supported":false,"code_challenge_methods_supported":["plain","S256"],"device_authorization_endpoint":"https://raspi5.XXYYZZ.ts.net/api/oidc/device/authorize","end_session_endpoint":"https://raspi5.XXYYZZ.ts.net/api/oidc/end-session","grant_types_supported":["authorization_code","refresh_token","urn:ietf:params:oauth:grant-type:device_code","client_credentials"],"id_token_signing_alg_values_supported":["RS256"],"introspection_endpoint":"https://raspi5.XXYYZZ.ts.net/api/oidc/introspect","introspection_endpoint_auth_methods_supported":["client_secret_basic","Bearer"],"issuer":"https://raspi5.XXYYZZ.ts.net","jwks_uri":"https://raspi5.XXYYZZ.ts.net/.well-known/jwks.json","prompt_values_supported":["none","login","consent","select_account"],"pushed_authorization_request_endpoint":"https://raspi5.XXYYZZ.ts.net/api/oidc/par","request_object_signing_alg_values_supported":["none"],"request_parameter_supported":true,"request_uri_parameter_supported":false,"require_pushed_authorization_requests":false,"response_modes_supported":["query","fragment","form_post"],"response_types_supported":["code"],"scopes_supported":["openid","profile","email","groups","offline_access"],"service_documentation":"https://pocket-id.org/docs","subject_types_supported":["public"],"token_endpoint":"https://raspi5.XXYYZZ.ts.net/api/oidc/token","token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_post","none"],"userinfo_endpoint":"https://raspi5.XXYYZZ.ts.net/api/oidc/userinfo"}

Only difference I see is the trailing / slash

[nicotsx]

Okay, I see the trailing slash might be the issue. I'll cut another release that will be less strict with the exact url

[nicotsx]

Update, seems like a bug or a new thing in better-auth. I will try to validate upstream if this is a bug or intended

[aszurnasirpal]

I can only confirm what @janreinhardt wrote. In my instance, 0.43.1 doesn't work with the Pocket-ID either. The newest version is still trying to connect via HTTP

[janreinhardt]

Nice Vader image 👍🏻 Im still with that mountain picture in PocketID
But my redirects are https only and working by now. Maybe you still got a http one in either Zerobyte or PocketIDs settings?

[laitco]

For me with v0.43.1 and https based configured base_url it is using http:// within claim url onto EntraID as redirect URI.