Hacker News Reader

Comment by carlsverre | Hacker News Reader

Pretty insightful observation on authentication. Using a password method that requires the client to compute a brute force resistant hash that takes ~100ms of cpu time is a non-starter for most serverless platforms.

I'm curious if Cloudflare, or other serverless platforms offer the ability to generate short lived JWTs assigned to each worker. Combined with some configuration (pub key exchange, claim setup, etc) a platform like Neon could use these JWTs to establish identity. Sorta SSO for workers without the CPU overhead.

Seems like a safer approach than basic auth with fixed pws.

View on HN

In Cloudflare Workers we like to represent things like this with "bindings". A binding is like an environment variable, except instead of containing a string, it contains a live object with methods that access the remote resource. Authentication is baked into this object, so the Worker code itself never has to see an API key at all. For example, if you have a Worker configured to use a KV namespace, you can write code like:

    let value = await env.MY_KV.get(keyName);

No setup needed, at least in code. You create the binding either through the configuration UI or API.

So far we've mostly used this technique to connect Workers to other Cloudflare-provided services like Workers KV, but I'm super-interested in the idea of third-party bindings. Hopefully, you'd be able to configure them through an OAuth-like flow, where the Cloudflare dashboard redirects you to the third-party service, that service prompts you for permission, then redirects back to Cloudflare, and you never have to copy/paste a single secret.

Of course, under the hood this would all be backed up by strong authentication, but it's high time we stop making application developers waste time thinking about this stuff.

(I'm the tech lead for Workers.)

Heck yes - this is the way. Make this available and you will unlock an entirely new ecosystem of CF worker plugins. A++

Could we use mTLS to do this with third parties?

https://developers.cloudflare.com/workers/runtime-apis/mtls/

My new hero, please update the documentation on the workers, bindings, and examples.

I can't cite examples while I'm being ushered by a distracted Uber driver but this explanation goes beyond the documents.

Also, please extend Cloud Workers to be written as NanoVMs.

This is basically how we do authentication in the Splitgraph DDN [0], which is kind of like a multi-tenant serverless Postgres.

We implement the Postgres frontend with a forked version of PgBouncer, and we changed the authentication method such that when the user authenticates, we issue them a JWT which we store as a session variable. That session variable has the same security properties as a cookie in a web browser (the user can change/manipulate it, but if it's signed by us we can trust its claims).

That's the simple explanation that skips over the multi-tenant part. I don't want to derail from the thread - Neon is very cool, and we are actually experimenting with it right now, for storing the Seafowl [1] catalog [2] when deploying to "scale to zero" services like Google Cloud Run or AWS Lambda, which don't have persistent storage.

[0] https://www.splitgraph.com/connect/query

[1] https://seafowl.io

[2] https://seafowl.io/docs/learning/architecture

Postgres also supports auth via SSL client certs, so that's perhaps another option. I don't know how well that maps to apis in Cloudflare and the server side of Neon.

This is a good idea... how much compute does SSL client cert auth require on the client side? I would suppose it has to produce a signature of some kind, perhaps signing a challenge from the server?

Client signs previous handshake messages with private key to prove it has possession of private key for client certificate.

It should be a lot faster than a purposefully slow kdf AFAIK.

Since serverless is basically just the PHP model with more languages (so: also basically just CGI) I'm waiting for them to balance clients onto as few machines as possible in each DC and add a (revolutionary! State-of-the-art!) connection-pooling agent to each one.

I reckon the current hype-cycle will be just about at its peak, when that happens.

(FWIW I like serverless—but then, I liked CGI, so of course I do)

We are working with the Cloudflare team and see if they can build it. This is a great idea.

Iirc lambda can use iam policies to connect to the database, and you can get a policy from the lambda conf of for more complex setup lambda can pick up authenticated user policies from an api gw

Reply on news.ycombinator.com