-
authcompanion2
An admin-friendly, User Management Server (with Passkeys & JWTs) - for seamless and secure integration of user authentication
-
SimpleWebAuthn
WebAuthn, Simplified. A collection of TypeScript-first libraries for simpler WebAuthn integration. Supports modern browsers, Node, Deno, and more.
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
passkey-authenticator-aaguids
This repo contains a community sourced list of AAGUIDs for passkey authenticators to help with naming in end user management UIs
-
keepassxc
KeePassXC is a cross-platform community-driven port of the Windows application “Keepass Password Safe”.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
I have a nodejs passkey implementation over at AuthC https://github.com/authcompanion/authcompanion2 a simple user management server. For javascript developers https://github.com/MasterKale/SimpleWebAuthn has been a good way to get started with a poc before venturing deeper into webauthn (passkeys) spec.
I have a nodejs passkey implementation over at AuthC https://github.com/authcompanion/authcompanion2 a simple user management server. For javascript developers https://github.com/MasterKale/SimpleWebAuthn has been a good way to get started with a poc before venturing deeper into webauthn (passkeys) spec.
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 in binary form (???) on their site. 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.
- 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/
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 in binary form (???) on their site. 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.
- 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/
These crop up every now and again but they never address my biggest concern, which how we (the users) can prevent abuse of https://w3c.github.io/webauthn/#attestation-object such that only those of us with approved devices are allowed to authenticate.
It's not hard to imagine Google and Apple and a few others finding ways to pressure authenticators into blocking access to users of devices that cannot prove that they're running firmware which bellyfeels ingsoc.
It's been a while, but I read through the OASIS spec for SAML for my implementation. There is a lot of yak shaving and I also had to implement XML Digital Signatures (XML-DS), and XML Canonicalization (C14N), but overall I don't think it took too long for something that worked, and was a library so I could just give it a key (or PKCS#11 handle) an identity and get back a SAML Assertion, which is fundamentally what I was after. It's available for viewing here [0].
[0] https://github.com/rkeene/saml-idp/blob/master/lib/saml/saml...
All phones ask for PIN or pattern in addition to face/fingerprint. Use that.
For the average user this is safe enough. (i.e) keep google/apple password safe. Then all is fine.
> exporting and FAANG lock-in
You don't ever have to even sign into FAANG if you can put up with inconvenience.
- Buy a U2F FIDO key like OPEN SOURCE https://solokeys.com/ or Yubikey etc