Comment by catlifeonmars 7 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.
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.
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?