roke_julian_lockhart requests the ability to choose a custom email address during OAuth2 SSO registration, rather than being forced to use the address provided by the identity provider. They argue this is necessary for users who utilize unique email aliases (plus addressing) for each account, especially those frequently creating temporary accounts on try.discourse.org where SSO otherwise saves time. The user notes that relying on try.discourse.org’s current configuration results in undesirable email addresses and that manually changing the email after registration defeats the convenience of SSO.
olivia clarifies that the auth_overrides_email setting controls whether providers can overwrite existing emails on subsequent logins, not the initial signup email. As a workaround, they suggest changing the email in preferences after registration, which will persist if auth_overrides_email is disabled. However, roke_julian_lockhart counters that this manual step consumes significant time, negating the benefits of SSO.
supermathie expresses hesitation about changing core authentication logic for such a niche use case. They suggest technical workarounds like using separate browser profiles for different identities or configuring email server rewrites to map complex local parts to a single inbox. In response, roke_julian_lockhart explains these workarounds are ineffective due to Discourse ID blocking their primary email domain and the incompatibility of SSO with enabled 2FA. They conclude that for users strictly managing aliases and security, Discourse ID currently serves only as a legacy single source of truth rather than a useful registration tool.
When I register for a Discourse account via OAuth2 SSO, I am forced to register with the e-mail address that was assigned to the account that I am registering with. However, this is antithetical to how I utilise e-mail addresses:
Consequently (but — also — regardless), I should be able to choose the e-mail address that I register with.
The reason that I care about this is that I create a lot of accounts at try.discourse.org., [1] because:
…so SSO saves me some time, by pre-filling some information. However, if I choose Discourse ID, a rather undesirable e-mail address is utilised, because:
auth_overrides_email is already disabled on try.discourse.org. This setting controls whether an external authentication provider can overwrite your account email on subsequent logins. It doesn’t control which email address you can use during signup.
As a workaround, you can change your email after registering under Preferences > Account and verify your preferred alias.
With the current settings, your updated email should remain unchanged when you log in again through Discourse ID.
@olivia, thanks. Indeed, and I could, instead, add Discourse ID SSO after account creation. However, not having to do this would save me quite a lot of time.
Yes, federated login methods use the metadata from the IdP for the creation of the user account.
I’d be extremely hesitant to recommend a change in core (especially in the sensitive paths) for such a niche use case.
For you, I’d recommend setting up multiple browser profiles, each tied to a different ID account. Then you can use those to quickly log into try.discourse.org.
I do something similar; each profile is tied to a different email on the backend that ends up in the same inbox.
To help support this (and other shenanigans), I have a particular mail domain that rewrites
If you didn’t want to do such a setup, I’d recommend creating a JS browser bookmark snippet that submitted the email change request for you once the account was created.
@supermathie, I am unable to do that in a way that’s of much use, because Discourse ID currently blocks my primary e-mail domain, as aforecited. Consequently, I am forced to utilise a fallback, which I would rather not directly receive mail via, even with a sub-address attached.
This debacle renders Discourse ID rather annoying to utilise, because, to avoid that, I must, first, manually create the account, then connect Discourse ID, thereby conferring none of the auto-fill advantages that it would otherwise provide.
Though, even that is somewhat futile for any real account, because enabling 2FA disables all SSO, too! Currently, for me, Discourse ID’s sole use is as a single source of truth, for accounts that I connected to it before enabling 2FA on them.
(Even utilising another SSO provider is an annoyance, because I attempt to strictly utilise one e-mail alias per account. Consequently, I would want to replace the chosen e-mail address even if I were able to utilise my chosen provider. I always end-up just connecting these after manually creating the account, before I enable 2FA.)
