Related: More service providers need to stop using email as the primary identifier (as Google’s docs recommend). When I changed my username on Google Apps, I spent a lot of time dealing with issues at Slack, Datadog, GoLinks, and others.
I've always presumed email was the most stable global identifier for a user, but that assumption appears to be wrong.
I might verify the number, and then stuff happens in the real world while I haven’t logged into your service, and someone new registers with my number.
The number is assigned to my account, but the new account can prove they own the number. If you’ve made the number unique, then you need special handling here.
Treat the email address like a name field: it's probably not going to change, but don't make it impossible to do so when someone wants to.
We're not talking random apps and services, we're talking about the big providers that are commonly used for SSO, where "just change ur primary key" is wildly impractical at best, and more likely impossible at their scale. That ship, as it were, has already sailed.
I think you might have misunderstood the point. Miscellaneous claims like email/preferred_username shouldn't be used to identify 3rd party logins. Apart from not necessarily being unique, they're also vulnerable to change. Changing your email shouldn't make you lose access to all your accounts. The point of the sub claim is that it's it's unique and stable.
yeah I know that. We basically do both. You create the account with the email/upn but we also save the oid and than we use the oid for matching. If the email changes we update it. If you started your account without the provider and than somebody configured domain+tenant id we first match via upn and after the first login it will use oid. User still uses upn to start the flow but the matching uses oid. But we are only dealing with b2b tough. And we have our own login site that of course needs a upn as well, thus the upn of Microsoft is the same as ours. If you change the upn on the Microsoft side you need to change the login upn on our side aswell. Another solution would‘ve been to have a unique logon site, in this case it would be possible to directly go to the IdP, but it does not matter that much with login_hint.
This happened to me, and I cannot use my comcast email with google services, and some others. I need a separate email address for job hunting, because google calendar will assume the provided email address is linked to google services, and the notifications will go to the other guy.
It is really fucking annoying.
Once someone has their own domain, it also opens up things such as hosting your own IdP (or paying a small monthly fee to have someone else host it for you) and sidestepping email entirely.
Sure, but requiring ordinary people to do this is essentially a nonstarter. The whole point of SSO is to minimize user friction. Requiring a user to also set up a special email account with another service is a dramatic increase in friction, and I expect that a large percentage of users simply won't do it. Why would they?
The docs, however, seem to be discussing the notion of the relying party's "user" object. For that … use a UUID, an auto-incrementing int, some artificial key, totally up to you. Link that user object with the (iss, sub) tuple above. But you should consider¹ whether user can adjust their authentication method with whatever you're building: e.g., if I change OIDC providers … can I adjust in your RP what IDP my account is connected to? (Same as I might need to update an email, or a password in a more classic login system.)
(¹The answer is also not always "yes", either; I work with a system where the IDP is pretty much fixed, because it's a party we trust. All signins have to come from that specific IDP, because again, the trust relationship. But, on the open web where I'm just building Kittenstagram, you don't care whether the user is signing in with Hooli's IDP, Joja's, etc.)
Plus this approach allows multiple accounts each associated with the same IDP account. Useful if the user needs multiple accounts for whatever reason.
I've always felt that email+email_verified would make much more sense.
I don't actually care about the email address being a unique person, just that they have access to it.
No one wants to build an application that has to invent its own id scheme or manage this complexity. That fact that the specs don't provide a solution here -- something like informing you when an email address is no longer valid (again, I get it, this is hard/impossible) -- means that the spec will always be in conflict with actual usage.
Every year I get several notifications that this guy has done something with his x-box, or registered a new device for something or other. It is absolutely nuts, and companies like Google refuse to let people like myself claim our own email addresses.
I'm in a similar situation, except in my case, the person providing the wrong email address never controlled it - it's firstnamelastname@gmail.com, which I signed up for when gmail was still invite only.
If I go to sign up for a service that someone else has signed up for with my email, I just do a password reset, and take control of the account. Either by transferring it to another email address that doesn't exist and then creating a new account, or if that doesn't work I just nuke the data.
It might be the most stable, but that doesn't mean you can assume that it's at all stable.
Also, email addresses can't be assumed to uniquely identify a single person -- lots of people share email accounts with others.
This worked fine in Google services and some of the many work applications using Google for auth, but some of them were using the email address as a global identifier in a way that broke down when I changed my name. The services that migrated successfully were using a more stable identifier that persisted despite the address change.
The right thing here is to offer APIs that fit the needs of the applications that will use them with as little extra responsibility as possible.
In this case, I'd have hoped that Google would set email_verified to false so that applications (or downstream IDPs) would know that they had to do extra verification.
I am not saying that my solution works today. I am saying that is a completely natural thing to want and the fact that it doesn't work or that we're even having this discussion is failure of the people who designed and implemented these specs.
No deeper understanding required.