DEV Community: Amr Abumady

Passkey Sign-In for a Small Site Without Storing Emails: The 5 Server Steps

Amr Abumady — Tue, 29 Sep 2026 06:31:34 +0000

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 flow in our open-source reference integration, clientn-session-starter (Node.js + PHP, MIT, with tests). It is not an SDK. You write server code, and the repo shows one complete, tested way to do it.

What your site gets instead of an email

After the visitor confirms with a passkey on clientn.com, your server receives a clientn_id (CN-…). That id stays the same for this person on your site and is different on every other site, so two sites can't match their users by it. You never receive a password or an email address.

The five server steps

Start a session. Your server calls POST /api/v1/sessions with your API key. ClientN returns a session id, a confirm URL, a QR code and a 4-character match code.
Bind it to this browser. Store a pending login tied to the browser: a random token in an HttpOnly cookie, and only its hash in your database. The page shows the QR code and the match code (clientn.js handles the display).
The person confirms. They open the confirm URL (a link on the same device, or the QR code on a phone), check that the match code and site name are right, and confirm with their passkey.
Verify the signed callback. ClientN POSTs a signed callback to your server. Verify the signature over the exact raw bytes. Check that the callback belongs to a pending login you started. Mark it confirmed in one atomic step.
Log the right browser in. The browser holding the pending cookie polls your /clientn/status. Once the login is confirmed, consume it exactly once, create a fresh session id and set your app cookie.

If the callback is lost, the status route can ask ClientN directly (GET /api/v1/sessions/{id}) and verify that signed answer the same way. You can also call POST /api/v1/sessions/{id}/redeliver within 30 minutes.

Why the flow is shaped like this

A few choices look fussy at first, but each one blocks a real attack:

Poll your own server, not ClientN. ClientN's public status only says the person tapped Confirm. You are logged in only after your server has accepted the signed callback.
Store the browser binding as a hash. Another browser that learns the session id still can't take over the login.
Consume the login once. In the test suite, five parallel polls create exactly one session.
Treat a repeated event as a no-op. Callbacks are retried 3 times, 5 seconds apart. Return 2xx as soon as you've recorded the event, and make the same event arriving again do nothing.

Both apps are tested against the same list: cross-site start is refused, the API key never reaches the browser, tampered or oversized callbacks are rejected, expired logins are refused, and a forged recovery answer is ignored.

Running it

# Node 22.5+ (built-in node:sqlite, no dependencies)
cd node && cp .env.example .env   # add your key + secret
npm start && npm test

# PHP 8.1+ with pdo_sqlite and curl
cd php && php tests/run.php

First register your site at clientn.com/dev and verify your domain with a DNS TXT record or a /.well-known/ file. Callbacks are sent over HTTPS on port 443 to your verified domain and don't follow redirects, so test on a real staging subdomain, not localhost.

Honest limits

Keys have no scopes yet: one key and secret per site. Rotating them ends any sign-ins in progress.
The demo apps use an in-memory rate limiter. Use your real shared limiter in production.
It only helps on sites that integrate it. It won't make the rest of the web private.
Website plans are free up to 1,000 logins per month until 2027-03-31.

Try the flow yourself on the live demo, or read the docs. If you run a small site, I'd like to hear which step would block you. That's the feedback I'm collecting this month.

What Google's €403M and $463M Fines Actually Mean for Your Login Table

Amr Abumady — Tue, 22 Sep 2026 06:37:57 +0000

Google was just fined €403M by Ireland's DPC and $463M in a separate action, both tied to how location and account data was collected and retained (Irish Times, 2026-09-21; ABC News). Neither fine is about a breach — it's about retention: data a company was allowed to collect but kept, correlated, or reused longer than the stated purpose required.

For small and mid-size sites, the same liability shows up in a much smaller, more boring place: your login table. Most auth systems ask for an email up front and keep it forever, whether or not the user ever comes back. That's a data-retention liability you're taking on for zero product benefit in the first session.

The pattern we've been building around

We've been working on ClientN, a free passkey-based sign-in you can drop into a site alongside (or instead of) email/password. Two things about the shape of it are relevant to the fines above, not because ClientN is a GDPR product, but because minimizing what you store is the actual fix, not a bigger cookie banner:

Each site gets a different anonymous ID for the same person (CN-xxxxx), not a shared identifier you could correlate against other sites.
You never see or store the person's email unless they explicitly opt to share it with you.

That's it — it doesn't replace your GDPR review, but it removes an entire category of data you'd otherwise be sitting on and eventually explaining to a regulator.

Trying it

Free for sites up to 1,000 logins/month:

Starter (Node + PHP, MIT licence): https://github.com/clientn/clientn-session-starter
Docs: https://clientn.com/docs
Live demo: https://clientn.com/demo
Dashboard: https://clientn.com/dev

Curious how other devs are thinking about minimizing account-data retention post-fines like these — what's in your login table today that doesn't need to be?

What the Revolut Breach Says About Storing Identity Documents Forever

Amr Abumady — Sun, 13 Sep 2026 06:34:33 +0000

Revolut confirmed this week that it sent customer passport scans and transaction records to attackers who impersonated a government agency with a forged legal request (Reuters, Sept 12). No server was hacked. No password was cracked. A human on the compliance side looked at a request that read like it came from law enforcement, and handed over the file.

This is the failure mode that's easy to miss when we talk about "data breaches." We spend enormous engineering effort on encryption at rest, encryption in transit, access logging, and SOC 2 audits, and then the actual leak happens because someone approved a request that looked legitimate enough. The data was sitting there, complete and exportable, waiting for exactly the right piece of social engineering.

The root problem isn't the process failure. It's that the data existed to be exported at all.

Most identity verification today follows the same shape: a site asks for a passport or ID scan, stores it (or a vendor stores it on the site's behalf), and keeps it indefinitely "in case we need it again" (for compliance, for support disputes, for re-verification). Every one of those stores is a future Revolut. The attacker doesn't need a zero-day; they need one convincing forged letter and one tired employee on a Friday.

We built ClientN around a different assumption: verification and storage don't have to be the same step.

When someone verifies as a real, unique human on ClientN, the ID/passport check and the face match happen once, and the raw documents aren't retained afterward: what persists is a cryptographic attestation, not the image. Each site the person then connects to gets a different anonymous ID (a CN- handle), scoped to that site, with no shared identifier a second party could correlate across services or exfiltrate in one shot. There's no central vault of passport scans sitting behind a support ticket queue for someone to social-engineer their way into, because the vault doesn't exist after the initial check is done.

This is a trade-off, not a magic fix. A site that genuinely needs an auditable copy of your ID for its own regulatory reasons (say, a bank) still needs to hold that copy. ClientN doesn't solve that problem, and it's not trying to be a KYC vendor for regulated finance. What it solves is the far more common case: sites that ask for identity verification purely to prove "this is one real human, not a bot or a Sybil farm," and then hold onto sensitive documents they never technically needed to keep. Passkey login for session security, a one-time Sybil-resistance check, an anonymous per-site ID, and nothing left over that a forged government letter could unlock.

If you're building anything that needs "prove you're a real, unique person" without needing "collect and retain their government ID forever," the demo is at clientn.com/demo and integration docs are at clientn.com/dev. Verified Human accounts start at $1/year during the launch window: clientn.com/signup.

Verified Human. Still Anonymous.

Why websites replaced passwords with sign-in codes — and what comes after

Amr Abumady — Fri, 04 Sep 2026 09:23:24 +0000

There's a recurring question on Hacker News that keeps resurfacing: why do so many websites now email you a sign-in code instead of asking for a password? It's a fair question, and the answer says a lot about where web authentication is heading — and about a gap almost nobody is solving.

The short version: passwords were always the wrong primitive

A password is a shared secret. You know it, the site stores a hash of it, and every breach is a race between their hashing and someone's GPU. Email codes ("magic codes") sidestep the stored-secret problem: the site never keeps anything you'd mind leaking, and the proof of identity is "you can read this inbox right now." That's genuinely better than a reused password. It's also why they spread so fast — they're cheap to bolt on and they kill the top support ticket ("I forgot my password").

But a code in your inbox is still a bearer proof. Anyone who can read that inbox — a forwarded email, a hijacked mail account, a shoulder-surfed screen — can sign in as you. It moves the weak link from the password to the mailbox; it doesn't remove it.

Passkeys are the actual fix

Passkeys (WebAuthn discoverable credentials) replace the shared secret with public-key cryptography bound to your device and unlocked by your fingerprint or face. The site stores a public key; the private key never leaves your hardware. There's nothing in the database worth stealing, nothing to phish, and nothing to type. This is the endpoint the "sign-in code" trend is stumbling toward: no password, no bearer token sitting in an inbox.

If you build web apps, this is the part worth internalizing: the industry has quietly agreed that the login secret should not be something a human types or an attacker can copy. The only debate left is the packaging.

The gap nobody talks about: "who" vs. "unique human"

Here's what neither passwords nor magic codes nor even passkeys solve on their own: is this a real, unique person — without me having to collect their identity?

Most sites answer that by hoarding data. They demand your email, your phone, sometimes your ID, and they store all of it so they can de-duplicate accounts and fight bots and Sybil attacks. You end up with the worst of both worlds: the site carries a breach liability it never wanted, and you hand over identifying data to every service you touch.

That's the problem we've been building ClientN around. The idea is to split the two jobs that authentication usually fuses together:

Prove you're a unique, real human — once. We verify a person with a passkey plus a layered "Verified Human" check (an email code, a card check, and an optional ID/passport + selfie face-match done on our own servers, encrypted at rest, never shared).
Give each site a different anonymous identifier for that person. A site sees a stable CN-… id that's unique to that site and reveals nothing else. The same human logging into two sites gets two unrelated ids, so the sites can't correlate you — but neither can be fooled into thinking one person is a thousand.

The login flow itself is not an OAuth redirect that leaks your identity to a broker. The site asks ClientN for a one-time session; you confirm on clientn.com with your passkey ("Do you want to sign in to example.com?"); we send the site back a signed, per-site anonymous id. The site gets "verified, unique, human" without ever getting you.

Verified Human. Still Anonymous.

That's the whole thesis in four words. The sign-in-code trend is a symptom of an industry that knows passwords are finished but hasn't decided what "identity" should mean online. Our bet is that the right answer is less identity, cryptographically proven — not more of it, stored in more databases.

If you want to see it working, there's a live demo forum whose only login is "Sign in with ClientN": https://clientn.com/demo. If you run a site and want to add it, the integration is a single <script> tag plus one signed callback — docs at https://clientn.com/dev. And if you just want your own Verified Human account, we're in early access at a $1/year launch price: https://clientn.com/signup.

Passwords are ending. The interesting question is what we replace them with — and whether we finally stop treating "prove you're human" as an excuse to collect everything about you.

ClientN Shield: Privacy-First Authentication for the Modern Web

Amr Abumady — Thu, 19 Mar 2026 13:04:32 +0000

Your Identity Shouldn't Be the Price of Admission

Every time you sign up for a service, you hand over your email, name, and personal data. ClientN Shield changes that.

What is ClientN Shield?

ClientN Shield is a privacy-first authentication platform launching H2 2026. It lets users sign in to any website without sharing personal information.

Key features:

Zero personal data shared with websites
Anonymous authentication that actually works
Your identity stays yours
Simple integration for developers

Try Our Privacy IQ Quiz

Think you know how your data is being used? Take our Privacy IQ Quiz and score 7+ to claim a free 3-month premium account!

Join the Waitlist

We're launching in H2 2026. Join the waitlist to be first in line.

What privacy challenges do you face as a developer? Let me know in the comments!