Using JWT to Establish a Trusted Context for Row Level Security
Original: Using JWT to establish a trusted context for Row Level Security
Key topics
Diving into the world of Row Level Security, a developer's clever use of JWT to establish a trusted context sparked a lively debate about the merits and pitfalls of JSON Web Tokens. Some commenters, like themafia, shared similar approaches using OAuth flows with custom attributes, while others, such as twosdai and MuteXR, chimed in on the known vulnerabilities and "nonsense" in the JWT standard. A heated discussion ensued, with some advocating for alternatives like PASETO and others pointing out that proper implementation, such as using the "kid" header and specifying algorithms during validation, can mitigate JWT's security risks. Amidst the disagreement, many appreciated the original post's informative take on using JWT for Row Level Security.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
3d
Peak period
8
72-84h
Avg / period
3.5
Based on 14 loaded comments
Key moments
- 01Story posted
Aug 29, 2025 at 9:32 AM EDT
4 months ago
Step 01 - 02First comment
Sep 1, 2025 at 6:14 PM EDT
3d after posting
Step 02 - 03Peak activity
8 comments in 72-84h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 3, 2025 at 6:25 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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
If you're trying to make the argument that because they can be insecure, we should not use JWTs. Thats not really a great argument for most people. JWTs provide a lot of value, and the idea of having some secure, validatable, and no network required check for authentication, or transporting information. Is too valuable for businesses. So we all use JWTs, they are a decent standard.
At the very least you should propose an alternative that people use besides JWTs if you're going to vaugly hand wave about the scary security issues of 2021 firebase, and 2020 Npm packages reported by Auth0.
PASETO: https://paseto.io
I thought this was common knowledge on HN?
> if you're going to vaugly hand wave about the scary security issues of 2021 firebase, and 2020 Npm packages reported by Auth0.
These are issues caused by the JWT standard.
https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...
Just as an aside but I would never say this, this is why people hate security teams. I'm a security 'expert' with 15+ years in the industry including speaking at DEFCON, Blackhat, and all that.
I had no idea about these issues and have never heard of PASETO until now! I'm actually a few months in into my startup and we are using JWT for a lot of stuff so this is very relevant. Thanks for sharing! But if I can't keep up with everything then devs who don't do this all day simply cannot.
The correct fix is to never trust the header for which algorithm you're using.
https://infosec.exchange/@sophieschmieg/115132001021790785
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/
The application supplied a session token when first querying the database. The database would make a call to the authentication server to verify it and obtain the roles associated with that session. If it had not seen that combination of roles before, it would build and cache access tables for them (needed for performance when using views for row level security). Then any further queries using that token were fast. This also worked with connection pooling.
It had some rough edges; we had to run periodic cleanup jobs to remove stale cached access tables and tokens. And even with them, enforcing row level security consumed about 30% of the database server performance!
But, it did work and remained in service for about 7 years. Eventually, they replaced it with something much simpler. I had left and nobody understood it anymore. Which I guess is a separate issue about doing unusual things with tech...
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.