Hacker News Reader

Comment by agilek | Hacker News Reader

And yet people still go with Sign in with Google as the only login method.

I’ve actually started ignoring services where that’s the only login possibility.

Sorry even if your platform is the greatest thing ever, but I’ll find a different tool. I’ve read one too many stories about Google (or Apple!) closing the entire account over some bullshit unnecessary reason like “fraudulent” gift card issues or whatever. I’m certain the affected people would’ve preferred to just pay back the amount in question instead of losing their entire Google Drive, or their 20 years of iCloud Photos or whatever.

It's the only reason I want to replace Tailscale with something else or look into self-host when have a bit of time during my vacation. They only allow login through a third party, which is a big no for me.

Tbf to Tailscale they allow any OIDC provider[1]. I wish this was more normalised, then we could have one login everywhere regardless of who hosts it (even if it's yourself).

[1] https://tailscale.com/docs/integrations/identity/custom-oidc

While that isn't convenient is you don't want to use the public identity providers, it should make you think about what makes your identity on the Internet, and consider to have your own identity provider on a DNS domain you control.

This is what headscale does, right? Manage private logins and keys for your tailnet from a vps? I haven't played with it but seems straightforward

I created my own AWS Cognito userpool just for tailscale. I recall the webfinger redirect was frustrating to get right but I refused to use Google/Apple as a gatekeeper to my own network so I had all the motivation to get it working.

I think you can use a passkey now.

Only for people invited to the Tailnet. To create your own account, you still need a third party.

You can host your own identity provider. Authentik, Keycloak, authelia or Zitadel work.

I don’t fully agree with tailscale’s decision to not want to be an identity provider but I understand it on some level. It simplifies their service greatly and the amount of asks for that will essentially have them build a full enterprise Entra-like solution that would be a constant maintain headache and they are not interested in that.

Beyond simplifying their service, it allows Tailscale to have reduced responsibilities (because of reduced collection of sensible data), and makes them a less interesting target for people wanting access to the data (wether illagally by hacking, or legally from government agencies). This probably makes them less attractive as targets for censorship.

It’s odd, I just saw my first one of these today. Some former Figma person linked an AI site comp designer.

I was going to give it a shot, but the only choice was a Google login.

So very weird.

It's not that weird. Building a modern accounts system is a lot of work and people don't like creating new accounts. So it's the path of least resistance for developers and users.

It's not even that it's hard to build a modern account system. It's that if you put your site behind a private / custom account system, and you post a link to it on HN (for example), everyone and their mother complains that it's requiring an email address and password. But if you put the same site behind a Google auth, most people wouldn't think twice to click the button.

I worked on the Google account system for a few years. I'd say it's a lot of work to beat it. Not necessarily "hard" for a team with the right skills, but certainly a lot of sweat, blood and tears.

A modern account system is expected to have, in rough implementation order: email confirmations, password strength checks, password reset emails, forgot password flows (=advanced ID verification as otherwise this becomes a backdoor into accounts), user profiles (+avatar image upload/recompression/hosting), usernames independent of email addresses along with ability to change usernames later, password brute forcing blockers, bulk signup prevention (=solid bot detection), abuse controls (can easily become a team of people), 2FA (SMS), 2FA (authenticator apps), 2FA (backup codes), 2FA (voice calls), 2FA (passkeys), 2FA: recovery when both factors are lost, enterprise SSO integration (SAML), enterprise SSO (Active Directory), fast global signout support (much harder than it looks), cookie theft mitigations, heuristic online login risk analysis to catch cases where an attacker knows the right password via phishing, support for signing the user in to multiple domains, audit logging so users can review their own sign-in history, age verification and restriction support, and possibly support for being logged in to multiple accounts in a single browser session.

Oh, that all has to be HA, and the account system is the keys to the kingdom so the security requirements are the strictest of any part of your system.

You might say we don't need all of that, but expectations rise over time. Maybe 20 years ago you could get away with a simple account system and an automatic forgot password flow that just assumes the user still has access to their email. Maybe today you still can write a simple system, if you don't expect to have many users and are willing to implicitly delegate identity to webmail providers anyway (the moment you assume the user has access to a secure email account you're basically doing Sign In With Google anyway for 90% of users). But if you roll your own accounts, and then the user gets phished and someone logs in from an obviously suspicious place with the right password, they won't say "yes that's my fault" anymore, they'll say "Google could block that log in, why didn't you?" or maybe "Why didn't you support 2FA? It's your fault".

> A modern account system is expected to have, in rough implementation order: email confirmations, password strength checks, password reset emails, forgot password flows (=advanced ID verification as otherwise this becomes a backdoor into accounts), user profiles (+avatar image upload/recompression/hosting), usernames independent of email addresses along with ability to change usernames later, password brute forcing blockers, bulk signup prevention (=solid bot detection), abuse controls (can easily become a team of people), 2FA (SMS), 2FA (authenticator apps), 2FA (backup codes), 2FA (voice calls), 2FA (passkeys), 2FA: recovery when both factors are lost, enterprise SSO integration (SAML), enterprise SSO (Active Directory), fast global signout support (much harder than it looks), cookie theft mitigations, heuristic online login risk analysis to catch cases where an attacker knows the right password via phishing, support for signing the user in to multiple domains, audit logging so users can review their own sign-in history, age verification and restriction support, and possibly support for being logged in to multiple accounts in a single browser session.

You don't need half of that. Even to this day, anthropic lets you log in by sending a code to your email. No password, no dealing with resets, no MFA. So yeah, you definitely don't need all of that.

That's what I said. If you're willing to implicitly rely on webmail provider's identity/auth systems then you can simplify - but that's not much different to just adding a Sign in with Google/Microsoft button. The identity is ultimately controlled by the email service and almost all users are on just two of those.

What web auth system doesn't rely on a user having a secure inbox? It is vastly different from signing in with an IdP, since I can use my email address regardless of who my mail provider is.

Obviously, the Google/Microsoft/Yahoo etc auth systems. Also: Meta's auth systems.

Auth has to bottom out somewhere. Webmail providers can't just delegate to other webmail providers.

Thank you for this. The whole attitude of "it's just [complex thing we take for granted], how hard could it be?" is exhausting.

I dunno, I’d say it’s never been easier.

If you’re building a paid service you’re probably already using cognito or supabase or something. That puts you a few clicks aways from 5+ other identity providers and normal accounts.

I am guessing that's because Sign in with Google is the least of the evil, as compared to other popular OAuth Sign-in options like Facebook, X...

It's the least evil of the evil options? Why not use one of the good options then?

A password manager has an almost as efficient UX

Google is more evil than X or Meta by some assessments

It’s funny how the tides shift. I remember the more dominant online position in the early 2010s being “I don’t want to create yet-another-account for your website. Just let me sign in with my google account”. I’m with you though

Because with the alternative they'll require you to "confirm your e-mail" instead of just picking a password

I'm actually more annoyed by having to pick passwords than confirming my email.

I'm opposite. If my email goes down, or I do not have access to it, I cannot login. With passwords I still can.

My email is with Google. They are less likely to go down than my password manager.

Until one day your Google account gets locked with an automatically generated message that you violated an unspecified rule. Good luck getting contact to a human support.

Well then you need a better password manager. Like a .kdbx file which is ~100% available, given enough copies I guess.

Then what’s the point of it all? Just use Google login.

Yes, that's what I'm doing, when it's available.

But it's not always an option, so a password manager is still a good idea.

Doesn't your password manager take care of that?

It does. But I haven't properly synced it across all my devices, yet. I know, my fault.

when in a rush I will put in gibberish instead going through the pw manager steps and rely on resetting the pw at a later time

Picking passwords is a job best left to password managers. You don't use a hand crank when riding an elevator, do you?

I am using a password manager.

Use a password manager to autogenerate them?

Considering the two different people who fat finger my email address when signing up for services, I wish more systems required a validation step.

Janet and Jake, I am sick of getting your stuff. Learn your actual email.

I guess the good aspect of sign in with Google is that it falls back nicely to sign-in via email which is very portable.

Reply on news.ycombinator.com