Day 8: Passkeys & WebAuthn : Passwordless Authentication with Redis, P-256 & Phishing Protection

In Day 8 of the PulseLedger system design series, we build a complete Passkey and WebAuthn authentication system for secure, passwordless sign-in. Instead of sending passwords to a server, passkeys use public-key cryptography. A user's device generates a key pair, the private key stays on the device, and PulseLedger stores only the public key. During login, the server creates a one-time challenge, the authenticator signs it after user verification, and the server validates the signature. This application demonstrates how modern WebAuthn and passkey authentication protects against attacks that traditional passwords cannot reliably prevent, including phishing and replay attacks. What We Build: Passkey registration using WebAuthn Passwordless sign-in with no email or password P-256 key generation and ECDSA signatures One-time authentication challenges Redis-backed challenges with a 5-minute TTL Single-use challenges using Redis `GETDEL` Discoverable credentials with `residentKey=required` Required user verification with biometric or PIN WebAuthn origin and RP ID validation Signature-counter validation Support for single-device and synced/multi-device passkeys Passkey authentication state through `amr` Session integration with existing password authentication Software authenticator for complete end-to-end testing Browser testing with Chrome DevTools' virtual authenticator Security Defenses Demonstrated: The application doesn't just implement the happy path—it deliberately tests the security boundaries. A replayed authentication response is rejected because the challenge is consumed immediately. A phishing site is rejected because the WebAuthn response contains the legitimate origin and RP ID information. A key created for another domain is rejected because its RP ID hash does not match PulseLedger. A cloned hardware credential can be detected through signature-counter validation when the authenticator supports counters. A device that skips the required biometric/PIN verification is rejected because `userVerification` is required. How WebAuthn Works: The registration flow creates a challenge and asks the user's authenticator to generate a credential. The server verifies the challenge, origin, RP ID hash, and user-verification flag before storing the credential's public key. During passwordless login, PulseLedger creates another one-time challenge. The discoverable passkey identifies the account without requiring the user to type an email address. The server consumes the challenge with Redis `GETDEL`, verifies the signed authentication data, checks the credential counter, and creates a normal application session. The private key never needs to be stored by PulseLedger. Redis Challenge Security: Redis is used to store pending WebAuthn flows: Each challenge expires after 300 seconds, and `GETDEL` ensures that reading a challenge also deletes it. This means a challenge cannot be reused—even if the authentication attempt fails. Authentication Architecture: Passkeys become a second way to start the existing Day 6 authentication session. Everything after authentication remains consistent, including: Access tokens Refresh-token rotation Membership RBAC Row-level security Tenant isolation The session records whether authentication occurred through a password or passkey using: `amr: ["pwd"]` or `amr: ["passkey"]` This also prepares the system for step-up authentication for sensitive operations such as owner management and payout changes. End-to-End Testing: A software authenticator is included so the entire WebAuthn flow can be tested without requiring a physical security key, browser automation, or mocked cryptographic responses. The test authenticator generates real P-256 keys, constructs authenticator data, handles COSE/CBOR encoding, and produces ECDSA signatures that are verified by the same WebAuthn library used by the application. The test suite includes attack scenarios involving: Wrong origins Foreign RP IDs Replayed challenges Skipped user verification Reversed signature counters Registration/login flow mismatches Run the Application: The application can run directly or with Docker: `./scripts/build.sh` `./scripts/run.sh` `./scripts/test.sh` `./scripts/verify.sh` `./scripts/demo.sh` The browser application runs on `localhost:4008`, while the backend listens on port `8008`. You can also use Chrome DevTools → WebAuthn → Virtual Authenticator to test passkey registration and passwordless sign-in without a physical device. #Passkeys #WebAuthn #Passwordless #Authentication #CyberSecurity #Security #Identity #IAM #FIDO2 #PublicKeyCryptography #PhishingProtection #Redis #Python #FastAPI #BackendDevelopment #SystemDesign #SoftwareEngineering #FinTech #PaymentSystems #SecureAuthentication #ZeroTrust #PulseLedger #WebDevelopment #Day8