4 ms·

it's just WebAuthn with an easier to understand name. However passkeys depends on a yet to be published standard for QR codes + bluetooth + websockets for doin

• candiddevmike 4y ago
  Just recently tried to add WebAuthn to an app and was shocked at how complicated the spec is and how quirky the implementation ends up being. The biggest thing I couldn't easily figure out is how to use it properly. It seems like hybrid auth with your phone or FIDO gives you sign in, and local could be used for sessions? It's hard to make heads or tails from it. The developer UX was also pretty bad, ArrayBuffers was a poor design choice for passing around what ultimately becomes JSON.
  • arianvanp 4y ago
    Webauthn L4 standardises on JSON serialisation luckily. Yes the spec is horribly complex unfortunately. In my own project I send the assertion and attestation as multipart/form-data. Which means I can just directly send the ArrayBuffers over the wire. PublicKeyCredential.prototype.toFormData = function (this: PublicKeyCredential) { const formData = new FormData() formData.append('type', this.type) formData.append('id', this.id) formData.append('rawId', new Blob([this.rawId])) switch (this.type) { case 'webauthn.get': if (!(this.response instanceof AuthenticatorAssertionResponse)) { throw new Error('Unknown type') } formData.append('response.authenticatorData', new Blob([this.response.authenticatorData])) formData.append('response.signature', new Blob([this.response.signature])) formData.append('response.clientDataJSON', new Blob([this.response.clientDataJSON])) if (this.response.userHandle) { formData.append('response.userHandle', new Blob([this.response.userHandle])) } case 'webauthn.create': if (!(this.response instanceof AuthenticatorAttestationResponse)) { throw new Error('Unknown type') } formData.append('response.attestationObject', new Blob([this.response.attestationObject])) formData.append('response.clientDataJSON', new Blob([this.response.clientDataJSON])) break default: throw new Error('Unknown type') } return formData } async solveChallenge(challenge: Challenge, credential: PublicKeyCredential) { const formData = credential.toFormData() await fetch(challenge.location, { method: 'POST', headers: {'content-type':'multipart/form-data'}, body: formData }) }
  • PassageNick 4y ago
    Yeah, it is non-trivial to implement, but not impossible. Some folks go that route. There are SaaS solutions that implement it for you and make it easy to include in your app.
  • dwaite 4y ago
    > Just recently tried to add WebAuthn to an app and was shocked at how complicated the spec is and how quirky the implementation ends up being. Yes, the spec has improved somewhat but it is still more about describing and exposing individual capabilities rather than serving as an implementers' guide. There are also usability differences in how the various platforms behave that can be difficult to navigate. In particular, it can be very difficult to restrict which options are presented to a user. My hope is that efforts like https://passkeys.dev https://passkeys.dev will serve to promote particular broad usability patterns (e.g. primary authentication) and serve to describe the choices and implementation within that context, as well as point people to libraries/products that may help get that experience. > It seems like hybrid auth with your phone or FIDO gives you sign in, and local could be used for sessions? by hybrid and local, do you mean the QR code based flow vs some local presented authentication system by the platform? Generally - no, they are the same in that they both provide authentication in the manner the user chose. Trying to say one is used for one authentication purpose and the other is used for a different purpose will just cause you to shoot yourself in the foot once they move from their desktop to their phone and the two roles switch. Instead, there are two main behaviors - passwordless use as a multi-factor system, and use as an additional factor after some other authentication mechanism. These map to discoverable vs non discoverable credentials, and whether you are requesting user verification. It is typically better to require these broadly and let the user choose whatever they want to use (their phone, their desktop, a security keyfob over NFC). Then, possibly react to their choice with additional checks. Outright rejection of the user choice is really limited to tightly controlled environments (such as enterprises who issue employees security key fobs). > The developer UX was also pretty bad, ArrayBuffers was a poor design choice for passing around what ultimately becomes JSON. Yes, its unfortunate - the guidance was that was the proper choice to make in JavaScript API, while it has made people have to build a lot of libraries to shuttle the (non-interoperable) data from their backend servers to the browser due to the lack of binary data types in JSON. Web Authentication Level 3 proposes additional API to handle serialization of the objects to and from JSON in a browser-consistent manner. I do not yet know of a polyfill for this, but eagerly await seeing one.
• dwaite 4y ago
  A passkey is just web authentication credential registered to have certain pre-existing capabilities so that you can have a particular user experience. Passkeys don't rely on this mechanism (although being able to authenticate your desktop using your cellphone is a very valuable user experience!) This upcoming mechanism is also meant to be used between platforms (or at least, a platform and an extremely robust authenticator). It is not meant to be used by a website or native application which want to just rely upon/consume credentials. If the browser/platform supports this mechanism, it will be presented to the user as a choice of how to authenticate.