Comment by clintonb
1 year ago
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.
What should providers be using?
I've always presumed email was the most stable global identifier for a user, but that assumption appears to be wrong.
If you're logging in with OIDC (as is the case w/ the OP), the combination of the issuer and the `sub` claim identify the user (the "subject"). The relying party (the system wanting to authenticate the user) just treats sub as an opaque string (unique within that issuer). The `email` claim is just the "End-User's preferred e-mail address." (And … "The RP MUST NOT rely upon this value being unique" … the end user's email might change … for whatever reason the end-user, or their IDP, might prefer. Also, any other IDP might claim that email as the preferred email, potentially truthfully, too.)
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.)
This is how we do it- sub+issuer associated with an account in our system. The user is issued a username for our system, they enter that then they are presented with the login options (eg password, IDP providers, etc). This also forces the customer organisation to specify exactly who they want to have access (which in a org with 10k+ employees of which only a few dozen need to login to us, that’s a good thing).
Plus this approach allows multiple accounts each associated with the same IDP account. Useful if the user needs multiple accounts for whatever reason.
I get it, but this is also, frankly, terrible. I should not be required to store your identifiers in my system in case order to login users.
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.
2 replies →
Just use an integer or GUID or something as primary key. It is still totally fine to use an email address as username, of course - just keep a separate email-to-user mapping and don't use the email itself as primary key.
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.
> Just use an integer or GUID or something as primary key
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.
1 reply →
I changed my last name when I got married, and at the time I had a work email address that looked like oldlastname@company.com on the company's Google Workspace. Given that oldlastname was no longer my name, I changed my email address to newlastnmae@company.com.
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.
I have a comcast email named after an old movie monster. Turns out that a former comcast customer once had the same account, and registered it with google (and others). Not only can I not use that address with google services, creating google calendar events using my email will sent the notification to the other guy (as a result, I created another email address for job interviews).
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.
If you own the Comcast email address, how is he registering anything with it? Wouldn't he need access to the email to verify his accounts?
2 replies →
> I've always presumed email was the most stable global identifier for a user, but that assumption appears to be wrong.
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.
The subject identifier, "sub".
Microsoft basically has no useful sub (sub is only useful when it comes to app credentials for Microsoft). It has oid, but if you want to support n-providers with just a login field and not a sign in with n button, than you have a problem. Or should the user know its entry lid and insert it into the username field? Most of the time you use an email and what Microsoft does in c# and their docs mean that you connect that with the oid. And also that’s why it’s stupid that Microsoft and google do not treat the email/preferred_username identifier that well. Because everybody changes the oidc spec
2 replies →
Curious to hear answers to this too. People forget usernames and that alone would lead to drop off. People are also reluctant to give out phone nos. which is anyway a terrible identifier and has the same issues as email.
Why can't the phone number be unique? I have a unique phone number and trust them as my email unless I transfer myself out of my country.
3 replies →
I disagree with GP. I think email is generally a solid identifier, and would be curious to know why they needed to change theirs.
Because comcast subscribers lose their email address when switching email providers, and the address becomes available to other subscribers.
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.
4 replies →
I can't agree. This guidance just pushes responsibility down onto application developers and I would expect most of them to either do nothing or implement guidance inconsistently.
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.
The OIDC spec does provide a stable identifier, and Google implements it properly. My Google Workspace address will always be verified, so your solution doesn’t apply. Changing my email address at Google itself won’t unverify it. Also, you’re still relying on developers to read the docs and properly implement the spec.
I think you missed the point. No application developer wants to use "sub" as the identifier; they want to use "email" or "phone" because these a) are actual ways to message a human and b) do not require a deep understanding of any technical spec to do the intuitively obvious thing.
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.
1 reply →