6 ms·

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 sp

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.

mattgreenrocks 3y 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.
- sirius87 3y ago
  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.
  - rajasimon 3y ago
    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.
    - JohnFen 3y ago
      Just like with email addresses, there are a nontrivial number of people who share the same phone number.
      - SoftTalker 3y ago
        Phone numbers are also recycled, probably much more often than email addresses.
    - kahnclusions 3y ago
      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.
- crote 3y ago
  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.
  - andygeorge 3y ago
    > 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.
    - saurik 3y ago
      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).
- lykahb 3y ago
  The subject identifier, "sub".
  - merb 3y ago
    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
    - frenchyatwork 3y ago
      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.
      - merb 3y ago
        No the sub is not unstable, it’s just the sub is unique per client_id. 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.
- apitman 3y ago
  I disagree with GP. I think email is generally a solid identifier, and would be curious to know why they needed to change theirs.
  - kagakuninja 3y ago
    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.
    - rngname22 3y ago
      also known in industry as Account Takover
    - apitman 3y ago
      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.
      - JohnFen 3y ago
        > This is solvable by using a more stable email provider, ideally with your own domain. 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?
        3y ago
- deathanatos 3y ago
  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.)
  - yardstick 3y ago
    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.
  - jbmsf 3y ago
    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.
- kagakuninja 3y ago
  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.
  - philote 3y ago
    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?
    - bobthecowboy 3y ago
      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.
    - kagakuninja 3y ago
      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.
- JohnFen 3y ago
  > 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.
- smeyer 3y ago
  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.
jbmsf 3y ago
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.
- clintonb 3y ago
  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.
  - jbmsf 3y ago
    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.
    - clintonb 3y ago
      I don’t see it as a failure of the spec, but developers failing to read said spec. By the way, I’m a developer who does want a stable ID for users authenticating via third-parties. The fact is that email addresses and phone numbers can change, and should not be considered stable identifiers. If folks want to extract that information from an ID token, they can; but, don’t use them as a primary key. No deeper understanding required.

mattgreenrocks 3y 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.

sirius87 3y ago
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.
- rajasimon 3y ago
  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.
  - JohnFen 3y ago
    Just like with email addresses, there are a nontrivial number of people who share the same phone number.
    - SoftTalker 3y ago
      Phone numbers are also recycled, probably much more often than email addresses.
  - kahnclusions 3y ago
    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.
crote 3y ago
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.
- andygeorge 3y ago
  > 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.
  - saurik 3y ago
    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).
lykahb 3y ago
The subject identifier, "sub".
- merb 3y ago
  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
  - frenchyatwork 3y ago
    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.
    - merb 3y ago
      No the sub is not unstable, it’s just the sub is unique per client_id. 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.
apitman 3y ago
I disagree with GP. I think email is generally a solid identifier, and would be curious to know why they needed to change theirs.
- kagakuninja 3y ago
  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.
  - rngname22 3y ago
    also known in industry as Account Takover
  - apitman 3y ago
    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.
    - JohnFen 3y ago
      > This is solvable by using a more stable email provider, ideally with your own domain. 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?
      - 3y ago
deathanatos 3y ago
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.)
- yardstick 3y ago
  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.
- jbmsf 3y ago
  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.
kagakuninja 3y ago
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.
- philote 3y ago
  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?
  - bobthecowboy 3y ago
    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.
  - kagakuninja 3y ago
    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.
JohnFen 3y ago
> 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.
smeyer 3y ago
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.

jbmsf 3y ago

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.

clintonb 3y ago
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.
- jbmsf 3y ago
  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.
  - clintonb 3y ago
    I don’t see it as a failure of the spec, but developers failing to read said spec. By the way, I’m a developer who does want a stable ID for users authenticating via third-parties. The fact is that email addresses and phone numbers can change, and should not be considered stable identifiers. If folks want to extract that information from an ID token, they can; but, don’t use them as a primary key. No deeper understanding required.