If you ever wanted to use Discourse as your authentication provider - now you can!
Over the last week I’ve written a small service which can be used to act as an OpenID connect/OAuth provider with discourse as a backend.
You can check out the code here:
Note that my primary use case was to authenticate to Nextcloud using Discourse, so it might not be working for your use case.
If something is not working as expected, or it is missing that certain feature to make it work for you, feel free to create an issue in the GitHub repository.
Awesome initiative! I always wanted Discourse to be usable as an OAuth provider, so it can easily be integrated with more tools. Making it an external small service makes a lot of sense too!
I like the sound of this and hope some communities decide to try it out!
I’d love to see OIDC supported by Discourse officially in addition to our bespoke Discourse Connect functionality, so we can offer a turnkey solution to our customers on standard and teams without having to rely on okta or the like.
Distrust is a separate service, so you need to deploy it as such. You can run it in a container as described in the README file. Note that for secure operation, you will also need a reverse proxy handling SSL Termination (I might implement this directly sometime in the future).
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:
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.
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.
