alt Hacker NewsUsing JWT to establish a trusted context for Row Level Security
Comments
PostgREST has been doing this for a long time https://docs.postgrest.org/en/v13/references/auth.html#jwt-b...
We do something similar except we use an existing OAuth flow and simply add custom attributes to the authorization token. That authorization token is then sent along with requests to various services and these attributes are picked out and then used to apply policies or output filtering as appropriate.
As a suggestion I would look to name the properties of your current token in such a way where they could be compatible with the embedded case.
https://github.com/tvondra/jwt_context/blob/10be23c0651f1099...
https://github.com/tvondra/jwt_context/blob/10be23c0651f1099...
https://github.com/tvondra/jwt_context/blob/10be23c0651f1099...
Oh look, the typical setup for a classical JWT vulnerability.
Prior art:
https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
https://github.com/firebase/php-jwt/issues/351
You should really consider not using JWT for new designs that don't a priori need to interop with JWT.
PASETO is less likely to create sadness: https://paseto.io
I built something similar for Neon[1]. We went with the route that the user sessions for JWT RLS had very few privileges, and that the context was managed by our ingress/connection pool. In our case, all incoming queries had to come via our sql-over-http interface, but that was mostly just to reduce scope rather than being integral to the security.
The general idea is that the connection pool ingress is trusted to provide the context properly, but the client is not. The pool would generate a random JWK for each connection and each request would use a newly signed JWT and the token ID is strictly monotonic, which makes any attempts for the client to smuggle their own token contexts in near impossible.
The JWTs the pool signs for each transaction will contain the claims that were correctly validated from the client.
A `DISCARD ALL` before returning the connection to the available pool will clear the context so it cannot be re-used and a new context must be provided fresh.
[1] https://github.com/neondatabase/pg_session_jwt/