Comment by grose | Hacker News Reader

Comment by grose | Hacker News Reader

Very thorough article, nice! I'll add some other pain points I experienced:

- You need to let users register more than 1 passkey, but how to show them which is which? There are lists like this one[1] and FIDO provides a (maybe irrelevant?) list on their site[2] stuck inside of a JWT. I ended up using that JSON list + registration date + browser UA that registered it + "currently using" indicator when the current session derives from that specific passkey. Still kind of feels like a mess.

- The popular libraries seem to follow a kind of "shadow spec" where they agreed on using the URL-friendly variant of base64, which doesn't have native browser support. Not a big deal (just a couple helper functions needed) but kind of confusing if you're trying to implement the client or server bits from scratch. [Edit: as explained by a reply below, this is part of the actual spec!]

- I still don't know whether it's possible to use both usernameless and usernameful passkeys simultaneously. The APIs seem to be mutually exclusive, differentiated by some options (some of which are already deprecated?) and requiring empty lists to be passed in certain places. I'm trying to bolt on passkeys to a pre-existing auth flow and all I want is the closest thing to "use the browser's built in password manager". Ended up giving up on resident keys for now.

[1]: https://github.com/passkeydeveloper/passkey-authenticator-aa...

[2]: https://fidoalliance.org/metadata/

> The popular libraries seem to follow a kind of "shadow spec" where they agreed on using the URL-friendly variant of base64

WebAuthn itself uses base64url rather than base64. See, e.g., the `id` field here: https://www.w3.org/TR/webauthn-2/#iface-pkcredential

(It was probably a mistake, but it predates me so I don't know the motivation.)

> I still don't know whether it's possible to use both usernameless and usernameful passkeys simultaneously.

Non-discoverable credentials can only be used if their credential ID is passed in an allowlist. Discoverable credentials (a.k.a. "resident" in the API, although that name is a bit misleading) _can_ be enumerated in an allowlist. So they can work together, but to have the allowlist you must collect a username first or have some other way of know which account is pertinent to the current session.

Aha, so it is part of the spec. Thanks for clarifying that. Appreciate the advice on discoverable credentials as well! I was probably leaving out the discoverable creds from the allowlist. Getting the timing down for when to ask for credentials was a bit tricky but I think I see the whole picture now.

I will say though, when it all works out it's a really nice way to log in, and my users are happy about it.

Do you allow users to rename their passkeys in your user interface? I very much like how GitHub handles this, take a look in that view if you have a GitHub account. You also get nice info like "Seen from this browser" and "Synced" (non device bound passkeys) indicators if applicable.

https://github.com/settings/security (Passkeys section)

https://docs.github.com/en/authentication/authenticating-wit...

That's a good idea, thanks for the suggestion! Maybe I'll let them rename the keys with the provider as the default name. Haven't played with GitHub's implementation yet but I'll play around with it.

We ask the user to name each passkey. One more modal dialog during registration, but seems to work well.

Reply on news.ycombinator.com