Blog on Gatekeep

How to add passkey login to Next.js

Wed, 28 Oct 2026 00:00:00 +0000

The quickest way to add passkey login to a Next.js app is to let a hosted passkey provider run the WebAuthn ceremony and connect to it with Auth.js as a standard OpenID Connect provider. You add one provider entry to auth.ts, expose the Auth.js route handlers, register the callback URL /api/auth/callback/gatekeep, and call signIn("gatekeep"). Users are sent to a sign-in page where they use Face ID, Touch ID, Windows Hello or a security key, and come back with a session. There’s no WebAuthn code in your app and no client secret.

EdDSA vs RS256 for signing JWTs

Sat, 24 Oct 2026 00:00:00 +0000

For signing JWTs, EdDSA with Ed25519 gives you much smaller keys and signatures than RS256, fast signing, deterministic signatures that don’t depend on a random number generator at signing time, and fewer parameters to get wrong. RS256 (RSA with SHA-256) has the advantage of near-universal library support and very cheap verification. If your verifiers use a modern JOSE library, EdDSA is the better default for new systems. If you must support old or constrained libraries that only know RS256, RS256 is still a safe choice with a 2048-bit or larger key.

Auth0 pricing in 2026, explained

Wed, 21 Oct 2026 00:00:00 +0000

Auth0 pricing in 2026 is based on monthly active users (MAU) and the plan you pick. The Free plan covers up to 25,000 MAU. Paid B2C plans start at $35 a month for Essentials and $240 a month for Professional, both at 500 MAU, and rise as your active users grow: at 10,000 MAU, Essentials is $700 a month and Professional is $1,600. B2B plans start higher, at $150 (Essentials) and $800 (Professional) a month. Enterprise is priced by sales.

Auth0 alternatives for passkey-first apps

Wed, 14 Oct 2026 00:00:00 +0000

The best Auth0 alternatives for a passkey-first app are the ones that speak standard OpenID Connect, treat passkeys as a primary sign-in method rather than an add-on, let you run sign-in on your own domain, and don’t tie your code to a proprietary SDK. Hosted options include Clerk, Amazon Cognito, Firebase Authentication and Gatekeep. If you’d rather run it yourself, Keycloak, Ory and Authentik are the common self-hosted choices.

Which one fits depends less on feature checklists and more on a few structural questions. This post covers those questions first, then walks through each category fairly. We build Gatekeep, so read our take with that in mind, and verify any provider’s current features and pricing on their own site.

Account recovery when users lose their passkey

Wed, 07 Oct 2026 00:00:00 +0000

When a user loses their passkey, the safest recovery flow sends a short-lived, single-use link to their verified email address, has them create a new passkey on their current device, and revokes every old passkey on the account in the same step. Most users never get that far: synced passkeys from iCloud Keychain, Google Password Manager or 1Password come back automatically when they sign in to a new phone or laptop. Recovery is for the remaining case, where every device holding the passkey is gone, reset or inaccessible.

Single sign-on across your own apps, without SAML

Wed, 30 Sep 2026 00:00:00 +0000

To get single sign-on across multiple apps you own, point every app at the same OpenID Connect identity provider. The user signs in once at the provider, which sets a session cookie on its own domain. When the user opens a second app, that app redirects to the provider as usual, the provider sees the existing session, and it sends them straight back with an authorization code, with no prompt. Each app keeps its own local session and its own tokens. No SAML, no shared cookies between your apps, and no custom token-passing code.

OAuth PKCE explained, with no client secret

Wed, 23 Sep 2026 00:00:00 +0000

PKCE (Proof Key for Code Exchange, pronounced “pixie”) protects the OAuth authorization code flow by making the app prove, at the token step, that it’s the same app that started the sign-in. Before redirecting, the app generates a random code verifier, hashes it with SHA-256 to get a code challenge, and sends only the challenge. When it later exchanges the authorization code for tokens, it sends the original verifier. The server hashes it and checks that it matches. An attacker who steals the code doesn’t have the verifier, so the code is useless to them, and no client secret is required.

Why passkeys stop phishing (and one-time codes don't)

Wed, 16 Sep 2026 00:00:00 +0000

Passkeys stop phishing because the browser, not the user, decides which website a credential is used for. Every passkey is bound to the domain it was created on, and the signature it produces includes the origin of the page that asked for it. A phishing site on a look-alike domain can’t get the browser to use your passkey at all, and if it relays a request to the real site, the origin in the signed response gives it away. One-time codes have no such binding: a code typed into a fake page works just as well when the attacker replays it on the real one.

Passkeys vs passwords, SMS codes and magic links

Wed, 09 Sep 2026 00:00:00 +0000

Passkeys beat passwords, SMS codes and magic links on security because they are the only one of the four where nothing reusable or phishable is ever typed, sent or stored on the server. A password can be guessed, reused, phished or leaked from a database. An SMS code can be phished in real time or intercepted through SIM swapping. A magic link inherits the security of the user’s inbox. A passkey is a private key that never leaves the user’s device and only signs for the exact website it was created on, so a fake site gets nothing it can use.

What are passkeys? A developer's guide

Tue, 01 Sep 2026 00:00:00 +0000

A passkey is a public-key credential that replaces a password. When a user creates one, their device generates a key pair: the private key stays on the device (or in a synced password manager), and your server stores only the public key. To sign in, the device proves it holds the private key by signing a fresh challenge from your server, after the user unlocks it with Face ID, Touch ID, Windows Hello, a screen lock PIN or a security key. Nothing secret ever crosses the network, and the credential only works on the website it was created for.