{
  "id": 10626048,
  "title": "Passkey Sign-In for a Small Site Without Storing Emails: The 5 Server Steps",
  "url": "https://urgent.news/2026/09/29/passkey-sign-in-for-a-small-site-without-storing-emails-the-5-server",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-29T06:31:34.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/clientnshield/passkey-sign-in-for-a-small-site-without-storing-emails-the-5-server-steps-3bo1"
  },
  "original_language": "en",
  "account": "This guide provides a walk-through for small websites on implementing passkey sign-in using ClientN, without the need to store users' emails. The system generates a unique clientn_id for each user, which remains consistent across sites but unique across them. No passwords or emails are ever shared with your server. The tutorial outlines five server steps: starting a session, binding it to the browser, confirming with a passkey, verifying the signed callback, and logging the user in.\n\nFirst, your server must call POST /api/v1/sessions with your API key to initiate a session. ClientN then responds with a session id, a confirm URL, a QR code, and a 4-character match code. Your server must store a pending login for the browser using a random token in an HttpOnly cookie, with only its hash stored in the database. A QR code and match code are displayed to the user for confirmation. Upon passkey confirmation, the server verifies the signed callback received from ClientN, marking the login as confirmed in a single atomic step. The user's session is then logged.\n\nA subsequent poll of your server's /clientn/status endpoint confirms the login. Once confirmed, a fresh session id is generated, and a fresh cookie is set. If the callback is lost, the status route can query ClientN directly to verify the callback. The flow discourages attacks by requiring server verification of callbacks, binding the browser with a hash, and ensuring the login is consumed only once. The tutorial emphasizes the importance of treating repeated events as no-ops and handling callback retries. Both Node.js and PHP implementations are provided for reference. The service is free for small sites, with a limit of 1,000 logins per month until March 31, 2027. The guide encourages feedback on any hurdles encountered while implementing this flow.",
  "summary": "I'm building ClientN, so read this as a founder's walkthrough, not a neutral review. Most small sites keep a users table with an email column only because the login needs one. The email then sits there for years, gets copied into backups, and turns up in breach notices. Passkeys remove the password. The question here is whether you can also stop receiving the email. This post walks through the…",
  "key_points": [
    "Server initiates session with POST /api/v1/sessions",
    "ClientN provides session id, confirm URL, QR code, match code",
    "Server stores pending login with random token in HttpOnly cookie"
  ],
  "editors_take": "This passkey sign-in guide for small sites shifts the authentication burden from servers to ClientN, eliminating the need to store user emails and reducing the risk of password and email exposure.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}