It's easy to DDOS your implementation #21
Description
Any postgrest application relying on pre-request for authentication is trivial to ddos and there is no way to block it.
PostgREST still has PostgREST/postgrest#1094 but at least that can be mitigated at the proxy level easily.
You've fixed a small problem (can't invalidate a JWT which can be easily worked around and that only affects 1 account) and created a big one, anyone without a valid session can mount a ddos attack (your service is trivially ddos-able, because "db-connection slots" are very limited and absolutely every request needs to execute this function, even the bad ones)
secondary point, i know pgcrypt docs say gen_random_bytes is cryptographically strong but i think the way you are using it is not.
Our definition of "strong" is that it's suitable for generating random
salts and query cancellation keys, during authentication.
That function (and the underlying libs it relies on) does not have enough entropy to be secure. (i am not crypto expert or even have exp. in the field but) If it were this trivial to generate random session ids, PHP would just use urandom output as session ids (as it's done here at the core) and not use things like user ip,time,... as entropy when generating the session id (and even then there were enough vulnerabilities in this area in the past).
as a conclusion: This is a good/interesting "exercise" but it's way less "secure" as implemented here then just plain JWT's (and certainly not as a "recommended" way to implement sessions).
If you are really worried about "revocation problems" of jwt (which imo are way overblown* in practice) you can trivially use something like https://github.com/bungle/lua-resty-session and replace on the fly JWTs with plain cookies at the proxy level.
* assuming jwt's are stored as cookies and have reasonable expiration time, like 1-2 hours, they would be extremely hard for an attacker to get their hands on (just like cookies). Even if a jwt is compromised, things like "linking it" with the ip from where it was generated drastically reduces what the attacker can do with a leaked jwt (and thus not even needing to implement a "blacklist", which again, it's not rocket science).