Sources here if you ae curious: https://github.com/bknd-io/bknd/tree/main/app/src/auth

Core auth feature progress is tracked here: https://github.com/bknd-io/bknd/issues/6

Broken (missing) auth is pretty common with Firebase/Supabase. It's a developer mistake that could happen in any kind of back-end, but I think that traditional back-end frameworks usually have better conventions that make the mistake less likely.

Yeah, I've never understood this. I can't think of any operation where I wouldn't want some backend logic in between. Firebase rules don't cut it.

Since you can embed bknd into any stack, and you can hook into system events, there are plenty of options to customize authorization according to your needs.

It does.. I know postgrest is like this though

Similar to Firebase it's multi-strategy based. You can use a combo of email/password or OAuth/OIDC (internally using https://github.com/panva/oauth4webapi) – currently there are 2 pre-configured (Google, Github), but it's easy to extend, so requests are welcome.

On the Authorization side, you can create roles and attach permissions to it. Those roles then get attached to users.

Claims are transported via JWT, you can configure its lifetime, secret and hashing. Currently it's stateless, meaning the token is not checked in a session store. But if there is demand, I'd prioritize adding this. I'm mainly exactly looking for feedback to prioritize next additions.

Hope this helps.

> (I haven't used a system like that. I'm intrigued by the idea of a backend that's just a database but it weirds me out not to have to write a layer that says who can read what. Exposing the database that nakedly feels super dangerous.)

In my (closed) product that exposes the database to the frontend, the "exposure" part has, effectively, row-level access control.[1]

[1] Also role-based using groups. I additionally mark the read-only queries as read-only and these are executed on a read-only replica.