Comment by catlifeonmars
10 hours ago
This is great. One thing that is not immediately obvious to me is what kind of authentication it supports. Needing to authenticate the caller is the #1 piece of boilerplate that gets in the way of me completing mini-projects. It’s not hard, but it’s definitely a nonzero amount of effort. And this is coming from someone who has implemented many, many auth flows professionally.
It doesn't say because there's no special support for any auth protocols. Long-term I want to have out-of-the-box support for things like OAuth (for user-facing auth) or mutual TLS (for device/service auth). _Technically_ there's currently support for the cryptographic primitives required to do JWT (I added that because I wanted to support WebPush w/ payloads for myself), but those aren't documented because I intend to remove the current slightly-hacky custom APIs and replace them with some off the shelf libraries, but I'm still figuring out user-added libraries (and on top of that I'll also need to figure out support for native libraries).
Are there any auth protocols / flows you think would be important to support?
Ah makes sense!
> Are there any auth protocols / flows you think would be important to support?
- I think API key passed via basic HTTP auth would get you pretty far. This is ideal for serving machine-machine requests and just requires that both parties can securely store the secret.
- OIDC is great for interactions that happen in the browser or if the function is serving multiple users, but is more complicated to setup and/or use correctly.
OpenID connect is probably the best for contexts where you want something served by multiple users and those users are humans.
> _Technically_ there's currently support for the cryptographic primitives required to do JWT (I added that because I wanted to support WebPush w/ payloads for myself)
This is probably a good intermediate solution FWIW - expose signature verification and HMAC APIs and allow a user to bring in their own implementation.