Distrust: Discourse as an OpenID Connect provider

Plugin Extras
12

I’m hoping to get some expert eyes on issues I’m facing while trying to use Discourse as an SSO provider.

My Goal: I’m setting up Discourse to handle authentication for another application (LibreChat). I’m using the standard DiscourseConnect provider functionality, with the distrust OIDC bridge service acting as the client that communicates with Discourse.

The Problem: The SSO flow works perfectly right up until the very last step. The user is correctly redirected from my app to Discourse, and they can log in successfully with their Discourse credentials. However, after logging in, they are redirected to my Discourse forum’s homepage (/) instead of back to the return_sso_url that was provided.

Where I’m Stuck (What I’ve Ruled Out): I’ve been troubleshooting this for a while and have confirmed this isn’t a simple configuration error. I have definitively ruled out the following:

  • Secrets: The discourse connect provider secrets are correctly configured. I’m using the plain domain (e.g., auth.my-site.com) without any protocol, and the secret key perfectly matches the one in my client service.
  • SSO Mode: I’ve confirmed enable discourse connect provider is checked, and the incorrect “SSO Client” settings are disabled.
  • User Policies: I’ve made sure must_approve_users is disabled, and my test user is an admin with a fully verified email.
  • Plugins: I have disabled all non-official third-party plugins and rebuilt the container, but the issue persists.

The Key Evidence: I have two definitive pieces of evidence that have me stumped:

  1. HAR File Analysis: I captured the entire network flow in a HAR file. It shows the POST request to /session for login is successful. The server immediately responds with a 302 Found redirect, but the Location header is consistently /. This proves Discourse is intentionally aborting the SSO redirect.
  2. Empty Rails Log: I then tailed the production.log file inside the container while attempting a login. Absolutely nothing is written to the log during this process. This tells me Discourse doesn’t see this as an error; it’s a deliberate, silent action.

My Question: Given that the login is successful, but the redirect is incorrect and there are no errors in the logs, what internal Discourse policy, pre-flight check, or hidden setting could be causing it to ignore the return_sso_url and redirect to the homepage instead? I feel like I’ve exhausted all the standard settings.

Thanks in advance for any ideas!