Open cazpr opened 2 years ago
We are having the same troubles with our oauth2-proxy / Keycloak integration This could indeed make the oauth2-proxy better
This has come up many times, and different people want different behaviour here. Realistically, we need to break the logic out so that there can be configuration of how someone would like to configure this, PRs are welcome for that if folks have ideas
Is it possible to describe different behaviours wanted by other people or link related tickets?
Instead of adding more options that need to be maintained, improving the needsRefresh
method could be the way to go.
If we check the expire date of IDToken when provider is oidc, then this might solve the problem. At the moment, this method relies only in the session age.
Check pull request. Are you able to verify this? It is just a proposal.
@miguelborges99 I briefly tested your changes but they seem to trigger a token refresh on every request so I guess something isn't working as expected.
Simply tweaking the needsRefresh method in stored_session.go as follows seems to do the trick for how we are using the proxy, but it might break stuff for other customers ....
// needsRefresh determines whether we should attempt to refresh a session or not.
func needsRefresh(refreshPeriod time.Duration, session *sessionsapi.SessionState) bool {
return refreshPeriod > time.Duration(0) && (session.Age() > refreshPeriod || session.IsExpired())
}
Simply tweaking the needsRefresh method in stored_session.go as follows seems to do the trick for how we are using the proxy, but it might break stuff for other customers ....
// needsRefresh determines whether we should attempt to refresh a session or not. func needsRefresh(refreshPeriod time.Duration, session *sessionsapi.SessionState) bool { return refreshPeriod > time.Duration(0) && (session.Age() > refreshPeriod || session.IsExpired()) }
Yes,you are right. It is also necessary to check if cookie has expired, I've incorporated that change. I'm also checking if ID token has expired, but I had the logic inverted. It was corrected.
re-tested it and seems to work.
@cazpr Thanks for your support.
Hi guys, is there any expectation to merge this https://github.com/oauth2-proxy/oauth2-proxy/pull/1955 ?
Only the mantainers can answer that.
I'm struggling to find time to review the PRs in this project right now, I will try to review the related PR and see if it resolves this issue
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
waiting for review...
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
To late to respond in time, but this issue is still relevant for us.
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
Issue still exists.
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
This issue is still relevant
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
This issue is still relevant
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
This issue is still relevant
Still relevant for us too :)
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
The issue is still relevant
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
still relevant
We've configured the oauth2-proxy (v7.3.0) to integrate with Keycloak via the oidc provider and to forward access tokens to our backend. Most of the time everything works as expected, but from time to time we notice that the access tokens (JWTs) that are forwarded by the proxy to our backend are rejected by the backend because they are expired.
The access tokens issued by Keycloak are valid for 5 minutes and we've configured to proxy to refresh its session after 4m30s. Keycloak has the concept of a "max session lifetime" which causes access tokens issues at the end of the Keycloak session to have a lifetime of less than 5 minutes. After obtaining an access token, the proxy seems to assume that its
SessionState
cookie is at least valid for the duration of cookie_refresh (4m30s in this case) but this isn't necessarily correct near the end of a Keycloak session.Let me illustrate this with an example.
Keycloak max session lifetime is 1h. A user logs in via the proxy at 00:00:00. The access token in
SessionState
expires at 00:05:00. The users keeps sending request to the proxy.All requests sent to the backend between 01:00:00 and 01:04:00 failed with a 401 response as the backend rejects the expired access token, but the proxy didn't redirect the user to the login page.
The following config is representative for what we're doing.
oauth2-proxy.cfg
alpha-config.yml
Expected Behavior
The oauth2-proxy should validate the
SessionState
regardless of whether or not the session needs to be refreshed.Current Behavior
The oauth2-proxy seems to skip session validation when the session doesn't need to be refreshed.
Possible Solution
Check
session.IsExpired()
regardless of whether the session was refreshed or not.Your Environment