Comment by mattgreenrocks
1 year ago
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.
1 year ago
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.
The email address is not guaranteed to be stable.
1 reply →
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.
Those providers already don't use email addresses as their primary key: their login APIs all allow you to get access to an underlying ID of the user (I say "an" as, in the case of Facebook at least, they no longer give you the global one but map you to an application-specific one, to prevent 3rd party apps doing correlation).
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?
Because a shocking number of services don't actually require you to verify you control the email address. I'm talking about mainstream services like Spotify.
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.
He used to own the account, now I own it. I've tried resetting the google account password and the like, there seems to be nothing I can do.
> 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
Is Microsoft's sub claim unstable?
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.
1 reply →
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.
Another edge case is that phone numbers get transferred and reused.
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.
Just like with email addresses, there are a nontrivial number of people who share the same phone number.
1 reply →
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.
This is solvable by using a more stable email provider, ideally with your own domain. And yes I know domains need to be much easier for the average person to use (and avoid accidentally losing). That's one reason I run a domain registrar, to try and make this more accessible.
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.
2 replies →
also known in industry as Account Takover