3 ms·

Why is the solution not OAuth/OIDC? Or maybe creating some sort of reduced OAuth "Anonymous-Site-Verifying-Your-Email-Exists" flow?

• thayne 11mo ago
  Not everyone uses an email provider that is also also an OIDC provider.
  • kbaker 11mo ago
    But not every email provider would support this new (from scratch) protocol either? Just don't see the need to reinvent OAuth but with a reduced scope for just email validation. Just add a happy path for this into OAuth itself?
    • thayne 11mo ago
      One other problem is there isn't a way to definitely know that a given OIDC provider is authoritive for a given email. Although, this spec could probably be simplified by just having a dns record that specifies the domain to use for oidc for emails on that domain. Another is that there is a lot of variance in OIDC and OAuth implementations, so getting login to work with any arbitrary identity provider is quite difficult.
      • blm126 11mo ago
        I wouldn't mix OAuth and OIDC up when thinking about this. OAuth is a chaotic ecosystem, but OIDC is fairly well standardized. OIDC actually does have a discovery mechanism standardized to convert an email address into an authoritative issuer. Then, it has a dynamic registration mechanism standardized so that an application could register to new issuers automatically. Those standards could absolutely be improved, but they already exist. The problem is that no one that mattered implemented them. If you want to get anywhere with something like this, you need buy-in from the big email providers(Google, Microsoft, Yahoo, and Apple) and the big enterprise single sign on providers(Ping, OneIdentity, and Okta). All of those companies already do OIDC fairly well. If they wanted this feature to exist, it already would. Instead, it seems like big tech is all-in on passkeys instead of fixing single sign on.
      • brody_hamer 11mo ago
        > a dns record that specifies the domain to use for oidc for emails on that domain. Oooh I like this idea!
        • 8organicbits 11mo ago
          Not a DNS record, no one uses dnssec so DNS is insecure. A .well-known path, with a TLS cert is better. Or a special subdomain, like MTA-STS uses.
    • TZubiri 11mo ago
      It's more of an invisible feature than a protocol. The signup protocol and user flow is the same if the feature is supported or not. You just skip a step if the convenience feature is supported. With SSO the user is inconvenienced with an additional option at sign up and login, and there's the risk of duplicate accounts. Also stronger vendor lock in.
  • TZubiri 11mo ago
    Additionally, some corporate or personal policies might prefer to NEVER use SSO, even if it is sometimes accepted. I hate being presented with option to login with email or login with Google, and I don't know which I signed up with. God forbid I accidentally make an account with SSO and another with email but the same email. I'd rather just always use email, it's supposed to be a convenience, the advantages are lost when it goes south once
    • thayne 11mo ago
      > God forbid I accidentally make an account with SSO and another with email but the same email. If they do it correctly, that shouldn't be possible.
      • TZubiri 11mo ago
        You can have both a gmail and a google workspace account with the same email, but I'm sure someone can do better than Google. Also I'm pretty sure that since google is itself an SSO provider, this add another layer of clusterfuck that I don't even want to think about, regardless of whether there's a clean implementation or not, I don't even want that on my mental capacity.