@@ -60,13 +60,15 @@ Two settings are used to configure the OAuth2 Proxy cookie lifetime:
6060
6161The "cookie-expire" value should be equal to the lifetime of the Refresh-Token that is issued by the OAuth2 authorization server.
6262If it expires earlier and is deleted by the browser, OAuth2 Proxy cannot find the stored Refresh-Tokens in Redis and thus cannot start
63−the refresh flow to get new Access-Tokens. If it is longer, it might be that the old Refresh-Token will be found in Redis but has already
63+the refresh flow to get a new Access-Token. If it is longer, it might be that the old Refresh-Token will be found in Redis but has already
6464expired.
6565
6666The "cookie-refresh" value controls when OAuth2 Proxy tries to refresh an Access-Token. If it is set to "0", the
67−Access-Token will never be refreshed, even it is already expired and there would be a valid Refresh-Token in the
68−available. If set, OAuth2 Proxy will refresh the Access-Token after this many seconds even if it is still valid.
69−Of course, it will also be refreshed after it has expired, as long as a Refresh Token is available.
67+Access-Token will never be refreshed, even if it is already expired and a valid Refresh-Token is available. If set, OAuth2-Proxy will
68+refresh the Access-Token after this many seconds whether it is still valid or not. According to the official OAuth2.0 specification
69+Access-Tokens are not required to follow a specific format. Therefore OAuth2-Proxy cannot check for any expiry date without an
70+introspection endpoint. If an Access-Token expires and you have not set a corresponding "cookie-refresh" value, you will likely
71+encounter expiry issues.
7072
7173Caveat: It can happen that the Access-Token is valid for e.g. "1m" and a request happens after exactly "59s".
7274It would pass OAuth2 Proxy and be forwarded to the backend but is just expired when the backend tries to validate