Integration into custom auth system where emails are not unique?

Well, yes. Of course that would be the case, and is what I’m targeting. I was looking for a solution that just disallowed login with an email at all, leaving username logins as the only method. I’m fine with essentially breaking email support entirely (no email notifications for example) by just giving totally fake emails from the oauth server. But that creates friction if the ability to use an email to login is still available, since users would attempt to do so and fail.

That would essentially force us to track 2 separate emails per user, which isn’t desirable either, and as mentioned by @supermathie is not even guaranteed to work with all providers, and still causes friction as we would have to now tell users about this forum-specific email address they have to remember.

Yes, that would work technically. But for obvious reasons would not be a real solution to use, as it would block all others from ever joining the forum.

This isn’t something we can do for technical reasons. The most obvious of which being that we already have users who have the same email address as other accounts. But the bigger one is that we simply can’t do this. The project we are looking to incorporate Discourse into is Pretendo Network, a server emulation project for Nintendo Network. Nintendo allowed their account system to reuse email addresses, and so to emulate the servers accurately we have to as well. Forcing unique emails is just not in our cards.

Someone on my team suggested we run our own SMTP server which handles mapping the fake emails for Discourse to our users actual emails, forwarding the emails sent from Discourse that way. Which would work, but obviously comes at a higher technical cost to us and still does not solve the issue of disabling email login and the aforementioned friction that comes with our case.

It seems like we may just have to fork Discourse or use another forum solution to do what we need.