I added passkey login this week. It's the rare feature that's better for security AND for the user

I added passkey authentication to BuildBase.app this week, and it turned into a better decision than I expected - so here's the honest version of why, including the part nobody mentions.

Quick context: BuildBase.app is a React/Next.js SDK that handles the SaaS backend I got tired of rebuilding - auth, workspaces, usage-based billing, notifications, the usual plumbing. Passkeys were the next auth method on the list, sitting alongside magic link, Google, GitHub, LinkedIn, Microsoft and email/password.

What a passkey actually is, if you haven't touched them: your users sign in with Face ID, a fingerprint, or a hardware security key. No password. And on the developer side, no provider credentials to configure - nothing to register with Google or Microsoft, no client secrets to rotate.

Why it ended up being worth more than a checkbox feature:

There's no password, which quietly deletes a whole category of work. No reset flow to build, nothing to leak in a breach, no "forgot password" support tickets. The most secure credential is the one that doesn't exist.

They're bound to the device, which makes them genuinely phishing-resistant. This is the part that matters - it's not a cosmetic security upgrade, it holds up against the kind of phishing that catches even careful users. Most "security features" tax the user. This one improves security and is often faster to use than typing a password.

Now the honest tradeoff, because I don't want to oversell it: passkeys can be tied to a device or ecosystem. If a user switches phones or loses a device, you don't want that to be their only way in. So I'd never ship passkeys as the sole method - you keep a fallback like magic link or email/password. It's an excellent default, not a complete auth strategy on its own.

The meta-point for anyone building a small SaaS and weighing auth methods: passkeys are one of the rare features that are better for security and better for the user at the same time, instead of trading one against the other. I moved them up my priority list because of that, and adding them was less work than I assumed - most of the WebAuthn complexity is the kind of thing that should live in your auth layer, not your app code.

For anyone who's shipped passkeys to real users: did people actually default to them, or did they stick with the login they already knew? That adoption question is the one I'm most curious about, and I don't have my own data yet.

It's live at https://buildbase.app if you want to see where it fits.