Ask HN: What's (in your opinion) the best authentication method for web apps?

I don't mind email and password. With password managers it's really not a thing I think much about.

Depends on what you're building though. Enterprisey customers will often require SSO and Google OAuth tends to keep them happy enough.

I hate those magic links, other stuff I have to open my email for. Same as TAN / similar "SMS" auth crap.

I just want to Command-Shift-L to autofill my username/password and if it needs an OTP then press Command-V to populate that too. This works with Bitwarden, on many "boring" websites. Unfortunately, does not with these fancy "enter your email first, and THEN we slide out the textbox with a slow animation just to break your flow" BS.

And no, I do not want to connect my github / gmail / twitter / microsoft / whatever account with any webpages. I have a password manager, and I have separate passwords (and sometimes emails) for the different websites.

I like to use passwordless email-auth, ie. send a magic link over email, they click it, and it cookies them, making them authenticated for some reasonable amount of time (like 1-7 days). Obviously not strong enough for important things like banking, but for small apps used by a couple of people, it's fine.

Another layed of meta-security I like to use for private apps is to use a service like ipapi.co to do an IP->geo lookup, and then have a per-used list of allowed geo regions (usually at the city level), like:

    {
        "jane@gmail.com":   ["New York"],
        "john@hotmail.com": ["Clowntown", "Buffoonville"],
        ...
    }

Depending on your user-base, this effectively shuts out 99%+ of the Internet. This geo check is trivial to circumvent if somebody really wants to, but it's good for keeping out 99% of random hackers.

If you accept id+password, either you are storing them, in which case you are a target (prepare to be boarded), or someone else is. If someone else is, you might as well use OAuth, and allow a choice of provider, but the integration effort is non-trivial (but far less than protecting your site against those looking to breach your hoard of stored treasure, other people’s passwords).

The other alternative is to support TOTP and let people use whatever authenticator they want.

Diversify social logins, and let people login with Github, Microsoft, Facebook...

I personally don't like opening another app to receive something that will help me login, especially since I pay for a password manager.

For most web apps I like magic link over email with cookie sessions that expire after 30 days. JWT for apis authorised by email magic links. No passwords to be hacked. No third party dependencies.

OAuth with the major options is the way to go. It's my preferred method of logging in because I don't need another set of credentials. Keycloak can be a great way to manage this for many apps that need OAuth.

Magic links, as you have noticed, are not what people want. I walk away from those sites that use them, just give me oauth

Best? Pgp or cert auth. Not the most practical.

Seriously just learn how to use and store a password hash and generate, store, and send a session id by cookie.

Kids are turning to services to do for them what has been a basic practice for decades.

Passwords are never going anywhere. Users are confused by passkeys, and they’re a terrible idea and terribly implemented anyway.

Edit: Learn how to use scrypt, learn how to execute `INSERT INTO users …`, and call a session library.

Was really hoping that Passkeys would already be in the comments, so I'll throw that into the mix myself.

Passkeys.

I'm on team magic links. Security can be greatly improved with 2FA, and for those who hate magic links/2FA, passkeys are a nice alternative.

I like Oauth, I like x509 even more. I don't like Passkeys, which are an attempt to decomplicate x509 by hiding them under layers - The abstraction is by necessity leaky enough that passkeys are more complex for users to understand, and they're a combination of too many different technologies and modes.

What’s the problem with magic links? If you have username/password combined with a “forgot password” feature, it’s the same as magic links with far more steps.

Also, usernames are generally a bad idea. Just use email. If they need a handle let them set it separately on their account and keep it away from auth.

I like it when sites give me options. Sign up or in with any combination of email, social, Github, etc. Afterward I can add a passkey or 2fa if I want to.

With a password manager it's all pretty straightforward.

I hate magic links. Way too many steps and have to wait for the email to transit the internet. It's as bad as a forgotten password, except it's every single time.

If Apple sign in is not available, I check for old-school sign up using an email. If neither are available, I do not signup.

Being used to automatic instant login with 1Password on most websites, forced magic email links are very frustrating. They make you switch windows, wait for the email to arrive, sometimes look for it in the spam folder, and finally also leave an unnecesary browser tab open. In my view, you should always offer a username/password/totp or at least passkey alternative.

I increasingly favor OAuth when I encounter the option, even though I resisted at first ("too many eggs in the google basket").

I am sick and tired of needing to conjure a unique 12-character password with 4 different keyset features in order to gain access to a coupon-clipping site, someone's blog about bundt cakes, or a forum discussing solar panels.

The exception is where loss of the credentials can do me real and meaningful financial harm. I have no problem managing unique, complex, and rotated passwords for these. I also expect 2FA for these at a minimum.

Everyone is doing this so terribly that I wish they'd all just farm it out. correct battery horse staple indeed. :)

TLS client certs

From UX and security perspective (especially for non-technical users), passkeys will be the default login method in the near future.