Comment by apitman
1 year ago
> I remember being surprised to learn that Microsoft would send Email claims that were not created or validated by Microsoft, and that the email claim in general was not considered reliable.
> This was counter-intuitive to me, because I had thought the entire purpose of OIDC was to establish reliable identity via a 3rd party like Microsoft.
That might have been the original intent, but I find it very useful that OIDC can be more flexible. For example, I run a free login provider[0], and it works by validating an identity with a 4th party identity provider (IdP) either with upstream OIDC or direct email, and creating a privacy screen between the app and that IdP (ie so Google can't track every app you're logging into). The fact that you can bring your own email to Google means you can get the security and UX of Google OIDC with the privacy of email + password, with the huge caveat that now you have to trust LastLogin instead of Google. But we're working on protocols to reduce that dependence.
> Google’s documentation in fact warned against using Email as an identifier
I completely disagree with Google on this. Email is the only truly federated identity that people actually use. Until we have something better widely deployed (and there are some promising alternatives in the works), I believe email addresses should be treated as identities.
[0]: https://lastlogin.io
> I believe email addresses should be treated as identities.
No, for two reasons:
Outside of the western world, phones are more common than computers and easier UIs in general so a phone number is more likely to be their identity.
In addition, that means you're completely handing off your identity to your email provider. Considering many - looking at you google - are faceless organizations that can and will shut down your access without notice or appeal, you could lose everything.
Background: I launched Okta's OAuth and OIDC products, put together LinkedIn's courses on the same, and doing it again at Pangea Cyber.
> Outside of the western world, phones are more common than computers and easier UIs in general so a phone number is more likely to be their identity.
When I worked at Stripe, we found that far more people lost access to phone numbers than email addresses. And the reason is simple: if you can't pay your phone bill, you lose your phone number.
While going through support tickets to tabulate which auth issues we should focus on, I came across one person who had a Stripe balance that they needed to feed their kid. But they couldn't log in because they couldn't pay their phone bill and had lost their number. The very fine support folks got the situation resolved with other identity checks, but it was a huge wakeup call.
You simply _cannot_ use an identifier that requires ongoing payment for identity purposes. You and I are probably privileged enough to never have to worry about this, but everyone who falls below the lower middle class is entirely vulnerable to losing _everything_ this way.
> you're completely handing off your identity to your email provider. Considering many - looking at you google - are faceless organizations that can and will shut down your access without notice or appeal, you could lose everything.
Versus handing off your phone number to organizations that routinely get socially engineered to transfer phone numbers. This is such a common attack that my mom knows about it. Ironically, the facelessness of most email providers also protects you from having your identity yoinked out from under you by one of their staff: I don't personally know a single person whose had their email turned off as a result of social engineering.
Plenty of other reasons to "lose" a phone number. Especially temporarily. Accounts deemed inactive. Locked devices, in some cases.
What makes the situation intolerable is the proliferation of Google-inspired "customer service" designed to prevent any prospect of useful contact with paying customers. Kafka-esq nightmares are currently an everyday hazard.
I'm not advocating for phone number, simply saying that "assuming/forcing email is insufficient"
Giving people the option between phone, email, or whatever is a better approach so they can plan accordingly.
Another common issue is moving countries which often changes your phone number.
Unless you're using PKC, you're completely handing off your identity to someone. The question is what's your threat model for having your identity taken from you. For me I've decided I trust DNS, because if it fails we probably have bigger problems. So email on a custom domain is as strong an identity as I require. I see a Gmail account as good enough for most people, but not for me personally.
Ideally I would like to see people hosting their own IdP servers from their laptops at home over something like ngrok but e2ee, but we have a ways to go for that.
Aside: given your background at Okta and ngrok, we have a lot of overlapping work. I'm curious of your thoughts on my LastLogin.io project?
Sadly more and more countries require mobile service providers to check identity of the user before providing a phone number. Not everyone wants to be easily identifiable IRL. Meanwhile, unique e-mail addresses are available by anyone without proof of identity.
And the goal more often is to identify a unique user, not have a user that can be traced back to real life.
> I believe email addresses should be treated as identities.
Because nobody ever shares an email address, and email is super secure
We can wait forever or we can begin building the solution
Sharing email identities is a reasonable way to give group access to a resource.
And solutions are being built. The mission of LastLogin is to accelerate this.
There's an important difference between email as an identifier in your own system, versus email as an identifier for a linked Google account. I agree with you that email works okay as an identity within a system you control, but agree with Google that it's a terrible way of linking with an external system: ephemeral, potentially tied to multiple accounts (!), and pointless when you've got an actual ID to use instead.
That's fair. I'm coming at this from the perspective that using Google SSO is great for UX, but a bad idea for privacy and vendor lock-in reasons.
I built LastLogin.io to provide the SSO UX without sacrificing privacy and to eventually move towards better protocols for user-controlled identity
I think it would be really great if you could compare/contrast LastLogin with Dex. Especially given they're both Go. Just curious if you evaluated dex, etc.
Also toyed with... Portier (nee Mozilla Persona). But ultimately dealing with this email normalization seemed like a losing/hard battle. And I mostly accepted that I'll likely die before a good solution is pioneered here and have refocus attention elsewhere. :/
See the table here: https://github.com/lastlogin-io/obligator#comparison-is-the-...
Hats off, what a README.