Comment by jbmsf
1 year 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.
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.
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.