Client OAuth2 login page wrongly redirected with https scheme

[donmor]

Describe the bug

I'm trying to add my deployment to owncloud desktop, and finally succeeded, but a problem occurred (previously reported as owncloud/client#12242 by @jlssmt)

Steps to reproduce

1. Deploy ocis
2. Install owncloud desktop
3. Try logging in with oauth2 in browser

Expected behavior

Log in normally

Actual behavior

Browser is redirected to https://127.0.0.1:<random_port>/... , which is obviously not accessible, reporting ERR_SSL_PROTOCOL_ERROR (or SSL_ERROR_RX_RECORD_TOO_LONG in firefox)

Setup

Please describe how you started the server and provide a list of relevant environment variables or configuration files.

Details

(Will add later)

Additional context

I solved this by changing https:// to http:// in address bar and press enter. This should be handled by owncloud. I'm not sure if this issue should be in owncloud/ocis, owncloud/web or owncloud/client.

[paul43210]

Hi @donmor, this is most likely a configuration issue rather than a code bug. The ownCloud desktop client correctly registers its OAuth2 callback as http://127.0.0.1:<port>/... (HTTP, not HTTPS), and the IDP's default client registration validates this as a native/local URI.

The redirect getting rewritten to https:// typically happens when:

1. OCIS_URL is set to https://... and the IDP uses the issuer's scheme to construct continuation URLs
2. Reverse proxy not forwarding X-Forwarded-Proto — if oCIS sits behind a reverse proxy (e.g., Nginx, Traefik), the proxy needs to send X-Forwarded-Proto: https so the IDP can distinguish between the external HTTPS scheme and the desktop client's local HTTP callback
3. PROXY_TLS setting — if oCIS terminates TLS itself, Go's net/http may assume HTTPS for all redirect URIs

Could you share your setup details? Specifically:

• Are you running oCIS behind a reverse proxy?
• What is your OCIS_URL set to?
• Are you terminating TLS at oCIS or at the proxy?

Also, the related desktop client issue owncloud/client#12242 may have additional context. This might be something the desktop client should handle by registering both http:// and https:// localhost callbacks, or the IDP should explicitly preserve the original redirect URI scheme for native app callbacks.

[donmor]

Could you share your setup details? Specifically:

* Are you running oCIS behind a reverse proxy?

* What is your `OCIS_URL` set to?

* Are you terminating TLS at oCIS or at the proxy?

• Yes, behind nginx
• Something like https://domain.name:XXXX/ (the site goes down if without https here)
• TLS terminated at nginx, with X-Forwarded-Proto = $scheme forwarded

[paul43210]

Thanks for the details @donmor. With TLS terminated at nginx, oCIS itself shouldn't be running TLS — they'd conflict. Try setting:

PROXY_TLS=false

This tells the oCIS proxy to listen on plain HTTP, and nginx handles HTTPS in front of it. Without this, oCIS listens on HTTPS too, and the OAuth2 redirect logic can get confused about the scheme since it sees the internal connection as HTTPS when nginx is already handling that layer.

Your OCIS_URL should still be https://domain.name:XXXX/ (the public-facing URL), but the proxy itself should speak plain HTTP to nginx internally.

This is how the official deployment examples work (with Traefik instead of nginx, but same principle). @jvillafanez also suggested this in #12088 for a similar setup.

[donmor]

PROXY_TLS=false

It's already false in my settings.

[paul43210]

@donmor Got it — if PROXY_TLS=false is already set, then oCIS is behaving correctly internally. The next thing to check is whether the IDP is actually sending an http:// redirect that the browser is upgrading to https:// on its own via CSP.

oCIS includes Content-Security-Policy: upgrade-insecure-requests on its responses. When that header is present on the consent/login page, the browser will silently rewrite any http:// URL it encounters — including the desktop client's http://127.0.0.1:<port>/... callback — to https://. That matches exactly what you're seeing.

To confirm this is the cause, in your browser's dev tools:

1. Open the Network tab before clicking through the OAuth flow.
2. After the login redirects you to the broken https://127.0.0.1:... page, find the response from oCIS (the IDP) just before the failure.
3. Look at the Location header on that response.

• If Location: is http://127.0.0.1:<port>/... → it's the browser doing the upgrade (CSP issue, server-side fix would be to omit upgrade-insecure-requests for the OAuth authorize endpoint, or for native-app redirect_uris).
• If Location: is already https://127.0.0.1:<port>/... → it's a server-side bug in the IDP rewriting the redirect_uri.

Could you grab that header and share it? That'll tell us exactly which side needs fixing.

[donmor]

Yes, the Location: part starts with https.

[jvillafanez]

You can try to use one of the deployment examples to verify if there is a problem with the desktop client.

As far as I know, oCIS doesn't set the Content-Security-Policy: upgrade-insecure-requests on its own, at least by default.
You can adjust the csp.yaml file used if needed (you can check https://github.com/owncloud/ocis/blob/master/deployments/examples/ocis_full/config/ocis/csp.yaml as part of the deployment example).

Maybe Nginx is the one adding the directive?

[paul43210]

Thanks @jvillafanez — confirmed, the default csp.yaml doesn't include upgrade-insecure-requests, so it's not coming from oCIS itself.

@donmor — that points at your nginx config as the likely source. Could you check your nginx site config (and any included snippets) for one of these:

add_header Content-Security-Policy "upgrade-insecure-requests" always;
add_header Content-Security-Policy "...; upgrade-insecure-requests" always;

Also worth checking:

add_header Strict-Transport-Security "...; includeSubDomains" always;

Quick way to verify from outside:

curl -sI https://your-domain/ | grep -iE 'content-security-policy|strict-transport-security'

If upgrade-insecure-requests shows up in the response headers, removing that directive from nginx (or scoping it so it doesn't apply to the IDP's authorize endpoint) should let the desktop client's http://127.0.0.1:<port>/ callback survive.

[donmor]

If upgrade-insecure-requests shows up in the response headers, removing that directive from nginx (or scoping it so it doesn't apply to the IDP's authorize endpoint) should let the desktop client's http://127.0.0.1:<port>/ callback survive.

No, I don't have such things in my nginx site config.

[jvillafanez]

Just to clarify, the problem happens only when using the desktop client, right? If you access through the web client or any mobile client, does it work?

Note that owncloud/client#12242 mentions OpenCloud, so I guess it was closed by himself because it was the wrong repo (and company), not because the issue was solved, if any. I don't think we can discard an issue with the desktop client yet.

[donmor]

Just to clarify, the problem happens only when using the desktop client, right? If you access through the web client or any mobile client, does it work?

Note that owncloud/client#12242 mentions OpenCloud, so I guess it was closed by himself because it was the wrong repo (and company), not because the issue was solved, if any. I don't think we can discard an issue with the desktop client yet.

Web / android client has no problem (I think so)

[dj4oC]

Before this can be acted on, the following needs to be resolved:

• Root cause is still unconfirmed after the thread. The reporter states the server's Location: header already begins with https:// (pointing at IDP/redirect logic), but the alternative CSP-upgrade theory was also raised — and the default deployment csp.yaml does not set upgrade-insecure-requests, and the reporter has no such nginx directive either. The actual origin of the scheme rewrite is not pinned down.
• Not confirmed whether the defect is in owncloud/ocis (IDP), owncloud/web, or owncloud/client: the reporter says web/Android clients work and only the desktop client is affected, and the referenced client issue (ERR_SSL_PROTOCOL_ERROR client#12242) was closed as wrong-repo, not fixed.
• A concrete reproducer against a current oCIS deployment example is needed, plus the full authorize request/response chain (the redirect_uri sent by the client and the exact response whose Location is rewritten to https://) to locate the responsible code path.

🤖 Automated by Claude Code

---

Generated by Claude Code