WebAuthN/Passkey Support

[jalcine]

Describe the Feature

WebAuthn is the nifty little feature that sites like Kayak, Amazon, Instagram, Google and others allow for folks to use device or software based authenticators to sign in without having to remember a password (could be password-backed, I use Bitwarden's passkeys in conjunction to Yubikeys. Blacksky already provides 2FA with e-mail (great and way more secure than SMS) but passkeys save a wee bit of time since it's all handled in the browser or device.

I'm curious to know how open of a contribution of this sort would be to the project. I already started looking into it and will link my branch on my fork later this week but if it's on a (private?) roadmap, I'd wouldn't want to overstep too much.

Attachments

No response

Describe Alternatives

Tangentially, it's one less thing to manage if folks opt to keep using e-mail 2FA. An alternative would be TOTP (or worse, HOTP).

Additional Context

No response

[jalcine]

Looking at this (and grimacing), this might require an extension + changes to rsky-pds since this yaps to that as the backend 🤔. There's also the bskyweb Go binary but my Go is weak.

[rudyfraser]

Blacksky.app is on the Bluesky TS PDS impl; would definitely need a PDS distro level change before any frontend work can begin.

[jalcine]

Hm. Out of a want to not introduce a (or extend an) lexicon for passkey management, would adding an endpoint for management be welcome? All would be require pre-existing authentication (sans the flow for attestation, that should be available without it but should rely on the DID to keep it unique - emails aren't).

[rudyfraser]

Open to it if:

• You can provide a plan/spec for the exact API you need (server-side). We don't need a formal lexicon. Instead you can look at how pds-gatekeeper exposes endpoints: plain REST under /gate/* (e.g. /gate/update-email, /gate/create-app-password) served as a sidecar behind the same reverse proxy as the PDS. The app detects support via the gatekeeper_version field on /xrpc/_health. Please follow a similar pattern (e.g. curl -s "https://blacksky.app/xrpc/_health" 2>&1 | python3 -m json.tool { "version": "0.4.193", "gatekeeper_version": "0.1.2-blacksky" }
• You build in affordances for PDS distros that don't support passkeys. We already had to carve out OAuth account deletion for this reason
• The spec addresses account migration. Passkeys are bound to a specific Relying Party (the PDS domain), so they don't follow a user when they migrate to another PDS. I don't want this to become a lock-in vector for our PDS. Need to address the migration UX and fallback path.
• The spec addresses recovery flow (what happens when a passkey is lost) and whether this is additive to password auth or replaces it.

[jalcine]

Been musing on this a bit, and I got some thoughts:

• I'm of the mind that the passkeys are an artifact of access to the PDS but not of repositories held on it; so they shouldn't be held in the scope of migration. Making them additive makes that doable since this'll be all opt-in (if someone comes to the appview advertising support for this implementation then we can use the expected route, otherwise nothing changes). That also keeps them out of the scope of migration (since folks can continue using their conventional auth options) and makes tying them to the blacksky.app domain as a RP simpler.
• Can you expand on the OAuth account deletion - was this is done with a specific scope? I wasn't aware of that being part of the OAuth spec (or as an extension).

Routes

The exact naming of the routes are flexible. I was hoping to make it into less endpoints but this is a lot more testable in Rocket (from playing around). Here's what I'm thinking would live in rsky-pds (have been experimenting with this locally):

Glossary

<access-token>: this would be the one that this (appview) sends to the PDS

Registration (requires existing auth, only used really from the settings screen)

POST /auth/passkey/register/init
Authorization: Bearer <access-token>
(JSON response) -> { challenge, rp, user, pubKeyCredParams, excludeCredentials, ... }

Since they're going to be logged in, nothing really needs to be sent from the client.

POST /auth/passkey/register/finish
Authorization: Bearer <access-token>
(JSON body) <- { credential: { id, rawId, type, response: { attestationObject, clientDataJSON }, transports } }
(JSON response) -> { credentialId, createdAt }

Meant to be called after the appview gets the proper bits from doing the Webauthn registration dance, can use https://simplewebauthn.dev/docs/packages/browser for this. But when that passes, the key is ready for use.

---

Login

POST /auth/passkey/login/init
(JSON response) <- { challenge, rpId, allowCredentials, userVerification }

So this part is interesting because it depends if we actually want to collect the ID for signing in. I'm of the mind to not do so because then you can do what GitHub does at https://github.com/login with the "Sign in with a passkey" button. Kayak does something where if you immediately open the login screen, it triggers this. Amazon, too, post-login, though for registration.

POST /auth/passkey/login/finish
<- { credential: { id, rawId, type, response: { authenticatorData, clientDataJSON, signature, userHandle } } }
-> { did, handle, accessJwt, refreshJwt, email, emailConfirmed, emailAuthFactor }
  // Trying to keep this the same shape as `com.atproto.server.createSession`

This is a bit of future proofing by keeping the shape the same (in the event that someone else figures out how to make passkeys portable or there's a DNS-level extension that comes out).

---

Management

All of this would be used by appviews to handle passkeys. Should restrict this by a scope of sorts because this is account security.

GET /auth/passkey/credentials
Authorization: Bearer <access-token>
-> { credentials: [{ credentialId, name, createdAt, lastUsedAt }] }

Gets all of the keys one has. Could collect a bit more information when we register keys to associate an emoji or device info but it's not really needed.

DELETE /auth/passkey/credentials/:credentialId
Authorization: Bearer <request-token>
<- 204 No Content

Does what it says on the tin (and IMO, it should always return this even if it doesn't exist).

Graceful Degradation

If one uses this appview and their PDS healthcheck endpoint is missing the key webauthn with the value true, we could mark that as a lack of support. This check would have to happen once on the login flow (thus prompting if login with passkeys is even possible). I don't see a reason to add some sort of refresh or check but I guess it can be done on login each time. If it's available, this would signal to the settings page (I figure this would live near the Email 2FA option) to show the button for management of keys. Tbh, it's not so bad to check on the health during login (but we should make it short and quick, to keep things snappy).