This has always worked like so. This BZ is therefore on the edge between a bug and an RFE. I think we might still address it somewhere in the lifecycle of 4.9.

sprint review: due to other high priority bugs we were not able to look here further

Hello,

I've done some digging through the oauth-proxy session handling code, which is a bit tangled. It turns out that it's not currently possible to validate the sessions as the state that is being kept does not in most cases contain the access token. Requests that follow the login with the OpenShift oauth-server no longer contain the access token that was retrieved from OpenShift and are identified solely based on the user's cookie.

In order to keep the access token on a successful login, we'd need to perform changes to how the oauth-proxy is being run by default, namely we'd have to set up a cipher for the cookie storage so that we can always store the access token within the session cookie.

I originally thought we could "just fix this" but unfortunately my expectations about the code were flawed. I'm going to have to ask you to open an RFE to validate the oauth-proxy sessions.