I does indeed bundle it's runtime into the executable, but this is not dissimilar from Go bundling it's gc into every executable.
Granted a compiled hello world Go program will be <2mb while a similar compiled Deno program will be more like 70. I imagine many usecases may not have a storage constraint though, and in that case why not?
Build Systems for C(++) are a mess, no package manager often means git submodules. Whereas Rust is actually easy, just requiring an `cargo install`. Don't know about Zig though Zig hasn't really taken of just yet imo.
You can but the server can require an device attestation during registration, proving that you're actually using an Yubikey or whatever. That isn't possible with TOTP
Not sure what you mean exactly - the product collects everything needed to verify the identity of a user. More like an api to handle the entire onboarding of a user
on the client side, it seems like it should be simple. in the time i allowed myself, i was not able to figure out how to integrate it server-side in my python app. you're not implementing your own crypto, but you are having to interact with and understnad crypto.
there doesn't seem to be a standard python implementation, and there's no feedback at all about what went wrong if your challenges/responses are not accepted by the client-side APIs. the error if your server-side implementation sends anything unexpected is essentially "no, that's wrong".
I would personally separate auth and the application. Configuring something like Keycloak or Authelia or one of the many other alternatives to do all the difficult work for you and just logging in through SSO/SAML seems much easier than having to keep track of your own authentication rules/security hashes/salting/etc. without making a mistake.
i spent a few minutes looking into it again, and remembered what i really found frustrating - it's all a weird mix of JSON, and byte arrays. some functions want json, and some functions want json encoded as a byte array. and some of the items in the json structure are supposed to be byte arrays?
it seems like they've gone out of their way to make it purposefully difficult to communicate between the client and the server. there's client examples to follow, and server examples to follow, but getting something between the two of them is a mystery. json doesn't have a byte array type, so making an api that depends on byte arrays in json seems needlessly obtuse. it's a standard that doesn't work without client-server communication, and it hasn't bothered to define a client-server communication method or use a datatype that can be natively communicated to the server?
That's just the browser client part of the equation, this says nothing about the server side. The `challenge` part of the API, as well as storing and maintaining the necessary public keys and doing the actual validation of credentials, are left for the reader to implement in the backend.
The browser API makes it easy to program a client against passkeys, but that doesn't necessarily hold up for doing the server implementation. For that, you need to either find a library that matches your requirements, or read through guides like these: https://developers.google.com/identity/passkeys/developer-gu... that skim over a lot of details.
reply