| From: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
|---|---|
| To: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
| Cc: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Hannu Krosing <hannuk(at)google(dot)com>, Ajit Awekar <ajitpostgres(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Dave Cramer <davecramer(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Subject: | Re: Periodic authorization expiration checks using GoAway message |
| Date: | 2025-12-12 11:49:23 |
| Message-ID: | CAN4CZFOKaU2dfO8Sq_0tAkcq1qq9jcXYKLmEBNDt=M1P3BV5yg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Would client side revalidation allow re-authentication while a
long-running query is in progress? Or would it kick out a connection
because it can't reauthenticate after some grace period? A strict OIDC
setup might use 5 or 10 minute access tokens, where this is a
realistic issue.
> Online checks (to allow revocation) would need more thought by the DBA; there's a performance-staleness tradeoff there.
Are revocation checks really related to GoAway? Even with offline OIDC
tokens, we can implement periodic server side checks to see if a long
lived token is still alive using an introspection endpoint.
I think this should be already possible with current validators, by
closing the connection if we find out that a token was revoked -
trying to implement this is on my TODO list. Should we really handle
this through GoAway, and allow a graceful period? If a token was
revoked, there's usually a good reason for that.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2025-12-12 12:22:38 | Re: Improve the performance of Unicode Normalization Forms. |
| Previous Message | Daniel Gustafsson | 2025-12-12 11:41:36 | Re: Serverside SNI support in libpq |