Observed behaviour:
Request with expired access token in kc-access token (and still valid refresh token in kc-state cookie) seems to properly refresh access token, properly propagate the newly refreshed access token towards upstream in Authorization header as well as X-Auth-Token headers. BUT is NOT returned in the response to the initial request. The response just does NOT have ANY set-cookie headers.
Gatekeeper logging wil show:
issuing access token for user {"email": "user@domain.tld", "expires": "2019-04-10T12:09:08Z", "duration": "59.697390679s"}
accces token for user has expired, attemping to refresh the token {"client_ip": "172.27.0.1:55514", "email": "user@domain.tld"}
injecting the refreshed access token cookie {"client_ip": "172.27.0.1:55514", "cookie_name": "kc-access", "email": "user@domain.tld", "expires_in": 59.947417593}
accces token for user has expired, attemping to refresh the token {"client_ip": "172.27.0.1:55524", "email": "user@domain.tld"}
injecting the refreshed access token cookie {"client_ip": "172.27.0.1:55524", "cookie_name": "kc-access", "email": "user@domain.tld", "expires_in": 59.426849615}
accces token for user has expired, attemping to refresh the token {"client_ip": "172.27.0.1:55524", "email": "user@domain.tld"}
injecting the refreshed access token cookie {"client_ip": "172.27.0.1:55524", "cookie_name": "kc-access", "email": "user@domain.tld", "expires_in": 59.354969865}
accces token for user has expired, attemping to refresh the token {"client_ip": "172.27.0.1:55524", "email": "user@domain.tld"}
injecting the refreshed access token cookie {"client_ip": "172.27.0.1:55524", "cookie_name": "kc-access", "email": "user@domain.tld", "expires_in": 59.84712772}
expected behaviour:
set-cookie header which overwrites the kc-access cookie with a NEW valid access token, in response to a request with expired access token (and still valid refresh token in kc-state cookie)
I did some digging, gate keeper DOES call http.setCookie and and the ResponseWriter w still has the header in a later state. However, in the actuall response the header is just NOT THERE.
What:
Observed behaviour: Request with expired access token in kc-access token (and still valid refresh token in kc-state cookie) seems to properly refresh access token, properly propagate the newly refreshed access token towards upstream in Authorization header as well as X-Auth-Token headers. BUT is NOT returned in the response to the initial request. The response just does NOT have ANY set-cookie headers.
Gatekeeper logging wil show: issuing access token for user {"email": "user@domain.tld", "expires": "2019-04-10T12:09:08Z", "duration": "59.697390679s"} accces token for user has expired, attemping to refresh the token {"client_ip": "172.27.0.1:55514", "email": "user@domain.tld"} injecting the refreshed access token cookie {"client_ip": "172.27.0.1:55514", "cookie_name": "kc-access", "email": "user@domain.tld", "expires_in": 59.947417593} accces token for user has expired, attemping to refresh the token {"client_ip": "172.27.0.1:55524", "email": "user@domain.tld"} injecting the refreshed access token cookie {"client_ip": "172.27.0.1:55524", "cookie_name": "kc-access", "email": "user@domain.tld", "expires_in": 59.426849615} accces token for user has expired, attemping to refresh the token {"client_ip": "172.27.0.1:55524", "email": "user@domain.tld"} injecting the refreshed access token cookie {"client_ip": "172.27.0.1:55524", "cookie_name": "kc-access", "email": "user@domain.tld", "expires_in": 59.354969865} accces token for user has expired, attemping to refresh the token {"client_ip": "172.27.0.1:55524", "email": "user@domain.tld"} injecting the refreshed access token cookie {"client_ip": "172.27.0.1:55524", "cookie_name": "kc-access", "email": "user@domain.tld", "expires_in": 59.84712772}
expected behaviour: set-cookie header which overwrites the kc-access cookie with a NEW valid access token, in response to a request with expired access token (and still valid refresh token in kc-state cookie)
I did some digging, gate keeper DOES call http.setCookie and and the ResponseWriter w still has the header in a later state. However, in the actuall response the header is just NOT THERE.
I also found a reddit post (https://www.reddit.com/r/golang/comments/b336x6/using_cookies_for_auth_with_gochi/) which seems to suggest a compairable problem lies within gochi. I could not further debug
Reference: