Corey James- 300 slife of a login challenge
- 1 daybefore the locking change was reverted
Hardware keys at the consent screen
Auth and access plane is the OAuth server through which commercial AI assistants and my own agents get access to my tool estate. The control point there is a person approving each grant on a consent screen. I added WebAuthn hardware-key sign-in to an alternate entrypoint of that server, so the person approving a grant can be asked to prove presence with a security key or platform authenticator instead of a password.
The flow around the protocol
The open-source python-fido2 library handles the FIDO2 protocol. My work is the flow around it. A visitor who reaches the authorize endpoint unauthenticated is sent to a login page. Registration binds a credential to the user. Login challenges expire, so an abandoned or half-finished ceremony cannot be replayed. Credentials sit in Redis with the rest of the server's session state. A successful assertion returns the visitor to the consent screen with the original authorization request intact, so a person returns to the exact grant they were approving. The ceremonies and their endpoints come to several hundred lines.
Where strong authentication belongs
Where to put hardware keys was the real decision. An earlier hardening change on the same server added an administrative lock to client registration and locked out every legitimate assistant, and I reverted it. The lesson was about where the control sits.
A person's consent is the control, and a stricter gate nobody can pass weakens the system.
So hardware keys strengthen the person who consents and leave the assistants' path unchanged. See The hardening fix that locked everyone out.