Rethinking Web Authentication: How ClientN’s Zero-Email Passkey Model Eliminates User Data Liability for Small Sites

By Tech & Security Desk
Published: October 2023

Main Facts: The Paradigm Shift in Modern Authentication

For decades, the standard operating procedure for web development has relied on a foundational, yet increasingly perilous, assumption: to identify a user, a website must collect and store their email address. From indie blogs and open-source project boards to niche e-commerce platforms and SaaS tools, databases are universally structured around a users table featuring an email column as the primary unique identifier.

However, this ubiquitous practice carries an inherent, long-term liability. Once collected, email addresses tend to linger indefinitely in production databases, find their way into automated backup snapshots, and ultimately surface in high-profile data breaches.

Amid the ongoing security evolution driven by passkeys—which successfully eliminate the vulnerability of traditional passwords—developer and founder Amr Abumady has introduced a provocative next step: eliminating the need to store user emails altogether.

Through a newly released open-source project called clientn-session-starter, Abumady and the team behind ClientN are demonstrating an architectural pattern that allows small-to-medium websites to authenticate users seamlessly using passkeys while keeping zero PII (Personally Identifiable Information) such as emails or passwords on their own servers. Instead of matching users via an email address, participating sites receive a cryptographically isolated, site-specific anonymous identifier known as a clientn_id.

This approach shifts the paradigm of user management. Sites no longer maintain user profiles in the traditional sense; instead, they maintain stateless authentication sessions tied exclusively to an opaque string that cannot be cross-referenced or correlated across different domains on the web.

Chronology: The Evolution of Passwordless to Zero-Knowledge Identity

To understand the significance of the ClientN session model, it is necessary to trace the trajectory of web authentication over the past several years:

• The Era of Passwords (Pre-2018): Web applications relied heavily on username/password combinations, forcing users to either memorize dozens of complex strings or reuse weak credentials. Security relied almost entirely on salting and hashing databases—methods frequently undermined by human error, credential stuffing, and brute-force attacks.
• The Rise of Federated Identity (2018–2022): "Sign in with Google," Apple, or Facebook gained widespread adoption. While convenient, this model concentrated identity power within a handful of massive tech conglomerates, tracking user browsing habits across the web and creating single points of failure.
• The Passkey Revolution (2022–Present): Backed by the FIDO Alliance, Apple, Google, and Microsoft, passkeys replaced passwords with cryptographic key pairs stored securely in device hardware (such as Apple’s iCloud Keychain or Google Password Manager). While passkeys solved the password problem, websites still largely relied on traditional backend account creation methods, usually requiring an email address to anchor the session.
• The Zero-Email Frontier (Current Development): Recognizing that stolen emails remain a primary vector for phishing, spam, and identity theft, developers began exploring decoupling authentication verification from database storage. The introduction of the clientn-session-starter reference implementation marks a distinct phase where identity providers act as trust brokers, passing only an isolated token to downstream sites without exposing the user’s underlying contact details.

Supporting Data: The Mechanics of the Five Server Steps

Building an identity layer without storing emails requires a meticulously engineered backend pipeline. The clientn-session-starter framework—provided in both Node.js (utilizing the built-in node:sqlite module with zero external dependencies) and PHP 8.1+—outlines a specific operational workflow.

While the exact implementation details depend on the host application, the architecture relies on a strict, five-step server-side transaction sequence:

1. Initiating the Authentication Handshake

When a user clicks "Sign in with ClientN" on a participating site, the host application generates a secure cryptographic challenge and redirects or requests an authentication token from the ClientN ecosystem.

2. Passkey Verification at the Edge

The user authenticates on their device using native biometric or hardware-backed passkeys (FaceID, TouchID, Windows Hello, or security keys) directly within the ClientN environment, keeping the private key entirely isolated from the target website.

3. Secure Token Delivery via Webhook/Callback

Once authenticated, ClientN dispatches a secure, signed HTTPS callback payload to the target site’s pre-registered webhook endpoint. This payload contains the unique clientn_id (prefixed with CN-), which serves as the temporary or persistent identifier for that user on that specific site.

4. Cryptographic Validation on the Host Server

The host site’s server receives the payload and immediately verifies its digital signature using pre-configured API secrets. This ensures the data originated unambiguously from ClientN and has not been intercepted or manipulated in transit.

5. Local Session Establishment

With the token validated, the host application establishes a standard local session (using secure, HTTP-only cookies) mapped strictly to the opaque clientn_id. At no point in this sequence does an email address, phone number, or password cross the wire or touch the host site’s database.

Robust Fallbacks and Recovery Mechanisms

Recognizing that network partitions or server hiccups can cause dropped callbacks, the architecture includes built-in redundancy:

• Status Polling: If a callback is missed, the host site’s status route can query ClientN directly via an authenticated endpoint (GET /api/v1/sessions/id) to verify the login state.
• Manual Redelivery: Developers can trigger a POST /api/v1/sessions/id/redeliver request within a strict 30-minute window following the initial authentication attempt.

Official Responses and Security Considerations: Defending Against Attack Vectors

Every authentication architecture must be evaluated through the lens of potential threat models. According to project maintainers, the architectural decisions built into the reference implementation were specifically chosen to block several common attack vectors:

• Cross-Site Request Forgery (CSRF) & Replay Attacks: Cross-site start requests are strictly validated and refused if the origin domain does not match verified parameters.
• Credential Leakage: API secrets and private keys never reach the browser environment, keeping sensitive operations restricted to server-to-server communication.
• Payload Tampering: Oversized or malformed callbacks are automatically rejected by strict schema and size validations on the server.
• Token Expiration and Forgery: Expired login sessions are systematically dropped, and forged recovery answers are ignored through rigorous cryptographic verification checks.

Running and Testing the Reference Implementation

Developers looking to audit or deploy the architecture can utilize the official open-source repositories. For Node.js environments (optimized for Node 22.5+):

cd node && cp .env.example .env   # Add your key + secret
npm start && npm test

For PHP environments (requiring PHP 8.1+ with pdo_sqlite and cURL):

cd php && php tests/run.php

To deploy in a production-like setting, developers must register their domain at clientn.com/dev and verify ownership using a DNS TXT record or a .well-known configuration file. Because callbacks are enforced over HTTPS on port 443 and intentionally do not follow redirects, testing must be performed on valid staging subdomains rather than unencrypted local environments (localhost).

Implications: The Future of Privacy-Centric Web Development

The introduction of zero-email passkey frameworks carries profound implications for the future of web engineering, legal compliance, and user privacy.

1. Drastic Reduction in Data Liability

For small development teams, indie hackers, and open-source maintainers, holding user data is a significant operational liability. Under regulations such as the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA), holding personal data subjects organizations to stringent erasure requests, security compliance audits, and severe regulatory penalties in the event of a breach. By adopting a zero-email architecture, sites structurally exempt themselves from vast categories of data risk. If a database running the clientn-session-starter is compromised in a security incident, attackers find only opaque, domain-locked strings (CN-xxxxx) that cannot be used to spam, dox, or spear-phish users elsewhere on the internet.

2. The End of Cross-Site User Tracking via Email Hashes

Historically, advertising networks and analytics providers have used hashed email addresses to track users across disparate properties. Because the clientn_id generated by this model is entirely unique per domain—meaning a user’s identifier on Site A bears no mathematical or relational resemblance to their identifier on Site B—the mechanism inherently preserves user privacy against cross-site correlation.

3. Honest Limitations and Market Adoption Hurdles

Despite its security benefits, the model introduces distinct trade-offs that developers must weigh carefully:

• Loss of Direct Communication Channels: Without a stored email address, site operators cannot send transactional emails, password resets (though passkeys render these obsolete anyway), newsletters, or marketing notifications directly to the user unless the user explicitly opts into a secondary, separate communication channel (such as a WebPush subscription or an independent mailing list).
• Dependency on an Identity Broker: While decentralized in spirit, the architecture relies on ClientN as an intermediary trust anchor to mediate the initial passkey challenge.
• User Friction: Consumers accustomed to traditional sign-up forms may initially find zero-email flows unfamiliar, requiring sites to invest in clear onboarding education.

As the tech industry continues to grapple with the unsustainable costs of data breaches and intrusive surveillance capitalism, architectural experiments like Amr Abumady’s zero-email passkey integration point toward a leaner, more secure web—one where convenience no longer requires sacrificing user privacy.