Re: [OAuth2] Infrastructure for tracking token expiry time

> Also, why is this defined in ValidatorModuleResult? If I interpret Zsolt's
> comment upthread correctly it was meant to be placed in OAuthValidatorCallbacks
> as a new callback - which I agree with would be better. The question of where
> and when to invoke it remains, but whatever we build I think it should be auth
> agnostic so that any auth can be hooked into it.

+1 Yes, that's what I meant. Also agree with the unnecessary expiry
timestamp with the callback - if we want to store some additional data
for the checks, that should be a void*, but with the single threaded
model there's no real need for it, the validator can store anything it
needs in global variables.

> 2. Terminating sessions with expired/revoked tokens before executing new
> commands.

> Token expiration is IMHO not a use case for a FATAL error, if we want to
> terminate a connection we can do it in a more graceful way.

There are different reasons for token expiration, one is a simple
timeout where all we have to do is communicate to the client that we
need a refresh (gracefully), and the other is where a token is
immediately revoked because of a security incident, in which case
immediate termination is a good practice.

There was an earlier discussion about it in the password expiration
thread[1], and the possible use of the GoAway[2] for it. Jacob
suggested making it user configurable, which seems like a reasonable
way to do it.

I also wanted to work on this patch, but I didn't start working on it
so far, because I wanted to see where those threads go, as the changes
introduced in them could be useful for the oauth token
refresh/disconnection mechanism.

[1] : https://www.postgresql.org/message-id/flat/CAER375OvH3_ONmc-SgUFpA6gv_d6eNj2KdZktzo-f_uqNwwWNw%40mail.gmail.com
[2] : https://www.postgresql.org/message-id/flat/DDPQ1RV5FE9U.I2WW34NGRD8Z%40jeltef.nl