You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 7, 2020. It is now read-only.
Gatekeeper makes use of a special "redirect_uri" cookie to encode the final landing URL where to redirect at the end of the authN handshake.
This cookie contains are URL, base64-encoded (with standard base64 encoding, not base64url encoding).
Many clients might by default URL-encode cookie content (e.g nodeJS express cookies),
resulting in % characters in lieu of "=" padding characters.
Gatekeeper should first URL-unescape the cookie value before attemting to base64-decode it.
In addition, gatekeeper currently ignores any error during this process, making it hard to figure out why redirection might fail.
Steps to reproduce:
setup a nodejs express client app which connects to gatekeeper's /oauth/authorize?state=none and expects to be redirected to itself by sending in request the request_uri cookie with its own URL (please adjust the URL so that some padding is present). Use standard base64 encoding with npm package 'base-64', not the native Buffer (which produces base64url encoding).
NOTE: even though the state query param is not returned, it is required for this cookie job to work and figure out the proper landing redirection.
=> inspect raw cookie content: remark that '=' padding signs have been translated to '%3D'
enter credentials then trace the final redirection after gatekeeper's /oauth/callback is invoked.
=> the Location header truncates the URL initially entersed in the redirect_uri cookie
Cause: during decode, no error is handled, resulting in a partial decoding of the cookie value (%3D values are not legal base64)
Variants:
with a reactJS client, using atob() functions and the 'js-cookie' package, the values where raw base64 (no additional URL-escaping)
extra URL escaping of values put in cookies is common place across middleware platforms for several languages (PHP, etc.)
What:
Gatekeeper makes use of a special "redirect_uri" cookie to encode the final landing URL where to redirect at the end of the authN handshake.
This cookie contains are URL, base64-encoded (with standard base64 encoding, not base64url encoding).
Many clients might by default URL-encode cookie content (e.g nodeJS express cookies),
resulting in % characters in lieu of "=" padding characters.
Gatekeeper should first URL-unescape the cookie value before attemting to base64-decode it.
In addition, gatekeeper currently ignores any error during this process, making it hard to figure out why redirection might fail.
Steps to reproduce:
NOTE: even though the state query param is not returned, it is required for this cookie job to work and figure out the proper landing redirection.
=> inspect raw cookie content: remark that '=' padding signs have been translated to '%3D'
=> the Location header truncates the URL initially entersed in the redirect_uri cookie
Cause: during decode, no error is handled, resulting in a partial decoding of the cookie value (%3D values are not legal base64)
Variants:
Reference:
KEYCLOAK-9794 - redirect_uri cookie parsing may fail on URL escaped content
[KEYCLOAK-9794] Fixed base64 encoding issues with redirect_uri cookie #467
The text was updated successfully, but these errors were encountered: