Comment by deathanatos
1 year 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.)
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.
I get it, but you're throwing technical specifications at a product/human/application problem.
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.