# SSO with non-unique email addresses? **URL:** \ **Category:** Product Support\ **Created:** [August 16, 2017, 1:14am UTC](https://meta.discourse.org/t/sso-with-non-unique-email-addresses/68125 "2017-08-16T01:14:30Z")\ **Posts on this page:** 1\ **Showing post:** 8
**Author:** ![Michael\_Ball](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michael_ball/32/121542_2.png) [@Michael\_Ball](https://meta.discourse.org/u/Michael_Ball)\ **Post date:** [January 3, 2020, 3:27am UTC](https://meta.discourse.org/t/sso-with-non-unique-email-addresses/68125/8 "2020-01-03T03:27:05Z")
We implement our own [Discourse SSO](https://meta.discourse.org/t/13045?silent=true) provider – so, it’s that system when can be adapted to send a unique email to Discourse. (e.g. `user@gmail.com` gets replaced with `user+internal_id@gmail.com`). When a user signs in, they don’t see any of thing, since they sign into our SSO system using their username. Ultimately, this isn’t perfect, since that doesn’t deliver emails for everyone, but it does avoid real email clashes when you have systems where the email is not unique. (Sadly, the particular app that I am working with also has fewer user name restrictions than discourse, so clashes are possible, though so far very unlikely.) I think the best long term solution may be to have a plugin which stores a separate _notification_ email address, and have SSO send over a unique (possibly even faked?) email address and one for notifications that does not need to be unique. I’m not sure yet whether that will seriously break things, but ~30 minutes of skimming code suggests it’s plausible, if not a painful solution. --- _[View the full topic](https://meta.discourse.org/t/sso-with-non-unique-email-addresses/68125)._