Refresh token

[fitzyjoe]

I would like to support shorter life for tokens. Typically, this is done with 2 tokens. A refresh-token that is used to obtain a short lived bearer token. However, I'd like to keep it simple for my partner apps that are under the umbrella of this single sign on.

I'm considering adding a feature to issue a new token as a Set-Cookie for requests that

• contain a valid token
• contain a token that is older than some short period (like a minute - to prevent issuing on every request)
• contains an authenticated-on JWT claim that has happened within a period (like a day - to prevent chaining these tokens forever)

[JoshMcCullough]

Hey buddy! Just doing some Fall cleaning here. I think a refresh token would perhaps be better handled by the end API / proxy target, which would add the Set-Cookie header on the response and it would naturally pass back through the chain. If we were to add support to the NGINX Auth JWT module to create new (refresh) tokens, we'd have to give it the private key to use to sign the token, and more config (e.g. whether or not the refresh token mechanism is enabled, how often to refresh the token (or within X seconds of expiration), how long the expiry should be, etc.).

Not sure if you have any additional thoughts, but I kind of assume you don't care about this any more. :) I'll close it for now!