Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

With the “keycloak” provider cookie-refresh does not work #501

Closed
devopsix opened this issue Apr 24, 2020 · 10 comments · May be fixed by #2601
Closed

With the “keycloak” provider cookie-refresh does not work #501

devopsix opened this issue Apr 24, 2020 · 10 comments · May be fixed by #2601

Comments

@devopsix
Copy link
Contributor

With the “keycloak” provider the cookie-refresh feature does not work. Instead of using the refresh token for acquiring a new access token in the background, the user is redirected to Keycloak.

Expected Behavior

Given a web page which is protected by OAuth2 Proxy configured to use Keycloak as the identity provider
and given a user has authenticated and has loaded the page
when the user reloads the page after the cookie-refresh duration is over and before the cookie-expire period is over
then the page should reload without any redirection occurring.

Current Behavior

Given the same as above
when the same as above
then the user is redirected to the Keycloak authentication endpoint, is automatically authenticated there by his SSO cookie, is redirected to the proxy's callback URL and is then redirected to the actual page.

Steps to Reproduce

Given the attached docker-compose.yml file:

  1. Run docker-compose up -d.
  2. Open http://localhost:8080/auth/admin in web browser and log in as user “keycloak” with password “keycloak”.
  3. Create realm “test” from realm-export.json.
  4. Create a user.
  5. Open http://localhost:8081 in web browser.
  6. Log in with the user's credentials.
  7. You see the “Welcome to nginx!” page.
  8. Wait for between 2 minutes and 4 minutes.
  9. Reload page.

Context

While this does not make much of a difference for loading a frontend page, it is an issue for background XHR requests in single-page apps.

With the “oidc” provider configured to use the same Keycloak instance as the identity provider cookie-refresh does work as expected. Try with http://localhost:8082.

Excerpt from OAuth2 Proxy log with “keycloak” provider:

[2020/04/24 13:47:29] [oauthproxy.go:872] Refreshing 1m41.402425162s old session cookie for Session{email:[email protected] user:[email protected] PreferredUsername: token:true created:2020-04-24 13:45:47.597574838 +0000 UTC} (refresh after 1m0s)
[2020/04/24 13:47:29] [internal_util.go:67] 400 GET http://keycloak:8080/auth/realms/test/protocol/openid-connect/userinfo?access_token=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJyZUxnWmRGVWdFVXZuM2kzUWpCUzNONVhjeGk3TzlTaHpwYVpRV0xuTXZnIn0.eyJleHAiOjE1ODc3MzYyNDcsImlhdCI6MTU4NzczNTk0NywiYXV0aF90aW1lIjoxNTg3NzM1NTQ4LCJqdGkiOiJiNTIwZGNmYy0zMGQyLTQxM2MtODlhZC1jYWEyZGNjZDA2MzQiLCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvdGVzdCIsImF1ZCI6ImFjY291bnQiLCJzdWIiOiJjMjRlM2RiMC0yMTZlLTQzZjUtYTg2YS04MTVmMTAwMDdiMDAiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJ0ZXN0Iiwic2Vzc2lvbl9zdGF0ZSI6ImJjZjczODkyLWQ5NWMtNGJhOS04ZTg2LWFiNTM3Y2UyMDk4MyIsImFjciI6IjAiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsib2ZmbGluZV9hY2Nlc3MiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY... {"error":"invalid_request","error_description":"Token not provided"}
[2020/04/24 13:47:29] [internal_util.go:72] token validation request failed: status 400 - {"error":"invalid_request","error_description":"Token not provided"}
[2020/04/24 13:47:29] [oauthproxy.go:896] Removing session: error validating Session{email:[email protected] user:[email protected] PreferredUsername: token:true created:2020-04-24 13:45:47.597574838 +0000 UTC}
172.20.0.1 - - [2020/04/24 13:47:29] localhost:8081 GET - "/" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.113 Safari/537.36" 302 300 0.005
[2020/04/24 13:47:29] [requests.go:25] 200 GET http://keycloak:8080/auth/realms/test/protocol/openid-connect/userinfo {"sub":"c24e3db0-216e-43f5-a86a-815f10007b00","email_verified":false,"name":"Anna Anyone","preferred_username":"anna","given_name":"Anna","family_name":"Anyone","email":"[email protected]"}
172.20.0.1 - [email protected] [2020/04/24 13:47:29] [AuthSuccess] Authenticated via OAuth2: Session{email:[email protected] user: PreferredUsername: token:true}
172.20.0.1 - - [2020/04/24 13:47:29] localhost:8081 GET - "/oauth2/callback?state=08abcb9c459cbcf58d19c9556a78f4cf%3A%2F&session_state=bcf73892-d95c-4ba9-8e86-ab537ce20983&code=fff6afa6-82de-4619-bd19-2958fdc415a6.bcf73892-d95c-4ba9-8e86-ab537ce20983.a2d7bfc2-5715-4182-bcb5-84f545b345f5" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.113 Safari/537.36" 302 24 0.016
172.20.0.1 - [email protected] [2020/04/24 13:47:29] localhost:8081 GET webservice:80 "/" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.113 Safari/537.36" 200 612 0.007

Excerpt from OAuth2 Proxy log with “oidc” provider:

[2020/04/24 14:48:48] [oauthproxy.go:872] Refreshing 4m12.099850485s old session cookie for Session{email:[email protected] user:c24e3db0-216e-43f5-a86a-815f10007b00 PreferredUsername:anna token:true id_token:true created:2020-04-24 14:44:35.900149515 +0000 UTC expires:2020-04-24 14:49:35.886329815 +0000 UTC refresh_token:true} (refresh after 1m0s)       
172.20.0.1 - [email protected] [2020/04/24 14:48:48] localhost:8082 GET webservice:80 "/" HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.113 Safari/537.36" 304 0 0.002

Environment

See docker-compose.xml and realm-export.json in keycloak-oauth2-proxy-example.zip.

Version used: v5.1.0

@JoelSpeed
Copy link
Member

The keycloak provider does not currently store refresh tokens in the session state and therefore cannot be used with session refreshing.

However, you should be able to use the OIDC provider with Keycloak instead, there have been several discussions related to this (eg #479) already, please let me know if you have any reason you cannot use the OIDC provider as is

@devopsix
Copy link
Contributor Author

Thanks a lot for your prompt response! I can use the OIDC provider as an alternative.

Until #479 has been resolved, users might appreciate finding this limitation mentioned in the documentation.

@JoelSpeed
Copy link
Member

Yeah we should put this in the docs, until that happens, hopefully users will find this issue and see our conversation

@steakunderscore
Copy link
Member

@devopsix are you able to open a PR to help us with our docs?

@devopsix
Copy link
Contributor Author

PR #543 created.

@devopsix
Copy link
Contributor Author

However, you should be able to use the OIDC provider with Keycloak instead, there have been several discussions related to this (eg #479) already, please let me know if you have any reason you cannot use the OIDC provider as is

It turned out that the OIDC provider does not work as an alternative for me. As far as I understand, the OIDC provider does not have a configuration option equivalent to --keycloak-group. But I do have to check group membership (or some claim, spoken more generically) for authorization.

@JoelSpeed
Copy link
Member

We should aim, long term, to unify these codebases and have a single --group flag of some description that checks claims within tokens assuming they are provided

@github-actions
Copy link
Contributor

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.

@github-actions github-actions bot added the Stale label Jul 11, 2020
@devopsix
Copy link
Contributor Author

Still relevant. PR #543 has a pending code owner review.

@JoelSpeed JoelSpeed removed the Stale label Jul 14, 2020
@github-actions
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants