We would like to integrate Discourse into our existing systems, to remove reliance on our Discord server for support. We already have our own account system setup, and would like to reuse it if possible to reduce friction. However email addresses are not required to be unique in our case, only usernames. It seems as though Discourse relies on the assumption that emails will be globally unique, which prevents us from directly integrating. I checked out DiscorseConnect which seemed promising, but states: Discourse uses emails to map external users to Discourse users Which would not work in our case, as multiple accounts can (and do) use the same email address. We then looked into Discourse OAuth2 Basic which at first glance did not require an email: The only mandatory attribute is id However later on it still mentions manually inputting an email address later if not provided by the oauth source: Notice I omitted the email path: SoundCloud do not provide an email so the user will have to provide and verify this when they sign up the first time on Discourse Would using Discourse still be something viable in our case? Having users manually provide an email address when logging in to Discourse for the first time would be fine in our case, but only if we can disable the ability to use an email address during the actual login process (requiring the use of only the username and password), since we can’t reliably map an email to a unique user. Being able to disable that from the login form entirely would remove friction on our end since it wouldn’t be something we’d support anyway, and would like to prevent users from even trying to do so.

[image] Jonathan Barrow: I may not have been clear originally, but the point of the post was seeing if it’s possible to force the login prompt to only accept usernames, As far as I know, it’s not possible to force the Discourse login prompt to only display the username field. You’d also be stuck trying to figure out how to get user’s registered in the first place. That’s why I’m suggesting DiscourseConnect. When DiscourseConnect is enabled, it become the only authentication system for your Discourse site. When users click the login button on Discourse, they’ll be automatically redirect to the URL that you’ve added to the discourse_connect_url site setting. Your auth system takes over from there. That means that if you have a site that users can currently login to with username and passwords, they’ll keep logging in that way. To set this up requires that you are able to add some code to the backend of the site that users are logging into now. It’s not that difficult to setup. There’s good example code to go from here: wp-discourse/lib/sso-provider/discourse-sso.php at main · discourse/wp-discourse · GitHub. You can also get some help with it on this forum. If adding code to your current site isn’t possible, you could also create a small web site that users can login to with usernames and passwords, then add the DiscourseConnect code to that site. It would be less work than forking Discourse.

Integration into custom auth system where emails are not unique?

Product Support SSO

Topic		Replies	Views
Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) Integrations sso , discourseconnect , configuring , how-to	46	461838	May 27, 2026
Use Discourse as an identity provider (SSO, DiscourseConnect) Integrations sso , discourseconnect , how-to	142	53379	November 9, 2024
DiscourseConnect Provider Questions WordPress	37	3784	September 5, 2023
Configure single sign-on (SSO) with WP Discourse and DiscourseConnect Administrators sso , wordpress , video , discourseconnect , how-to	19	7017	November 24, 2025
Merging existing Discourse and WP user lists WordPress	37	3763	May 28, 2019

Integration into custom auth system where emails are not unique?

Related topics