That’s interesting. How does it deal with authentication and authorization? It it handles those well, it could be a real “serverless” solution for most CRUD apps.
> 1. A user signs up. Supabase creates a new user in the auth.users table.
> 2. Supabase returns a new JWT, which contains the user's UUID.
> 3. Every request to your database also sends the JWT.
> 4. Postgres inspects the JWT to determine the user making the request.
> 5. The user's UID can be used in policies to restrict access to rows.
> Supabase provides a special function in Postgres, auth.uid(), which extracts the user's UID from the JWT. This is especially useful when creating policies.
For instance, say you have a `todos` table and want to make it so users can only read their own todos - you could have an RLS policy `todos.user_id = auth.uid()`. Afterward, `SELECT * FROM todos` will only return the authenticated user's todos. (Equivalent to manually issuing `SELECT * FROM todos WHERE todos.user_id = auth.uid()`.)
There's also `auth.role()` so you can easily restrict access by role: `auth.role() = "admin"`
Is there integrated way to achieve claim based approach where access to a given resource is governed by both uid (lets say org uid, and all users belong to particular org) and set of claims (lets say there are at least CRUD claims for all tables and I can set for any user any combination of them, or create a role containing them then assign that role to a user) ?
The extension is compatible with your existing row level security policies. If you connect to the database as a role like `authenticated` then those policies will be applied.
The columns and tables that are visible are also controlled by the role.
One cool thing about that approach is you could run e.g. an admin API and a user facing API all from that same endpoint by executing as different postgres roles!
