I am trying to set up Cloudflare Access in front of two web apps:
My goal is to leverage Cloudflare Access JWT for setting up SSO between these two apps as described here:
[…] applications can use the JSON web token (JWT) that Access generates to validate the user’s identity. Doing so enables a single sign-on experience.
Single sign-on integrations allow supported applications to connect the identity from the Access JWT to a user profile configured in the application. This way the user only needs to log in once, through the identity provider they select on the Access login page.
I’ve set up a blanket access policy to cover
myserver.com (no path). All requests to either apps are then scanned and properly redirected to my
custom.cloudflareaccess.com launch page for authentication against one of the IdP I set up (Google in that case) in case the
CF_Authorization cookie is missing or the JWT it contains has expired.
Question 1: when I click the red “Revoke Existing Tokens” button from the policy modal, I’m expecting the next request to any URL to
myserver.com/* to require authentication. Instead, I can continue navigating without interruption. Why? In comparison, clicking on the “Revoke session” link next to my individual user session exhibits the expected behaviour, by redirecting me to the login screen on page refresh.
Question 1.1: removing the
CF_Authorization cookie from
myserver.com does not trigger re-authentication either. The only thing that does at that point, is the following sequence:
- A - removing
CF_Authorizationcookie from both
- B - visiting
- C - visiting
myserver.com→ properly redirected to the login screen
If I refresh
myserver.com before B, the
CF_Authorization cookie reappears, as if the token never got revoked. Why?
Question 2: once the JWT expires, users are redirected to the login screen, even if they are still actively using
myserver.com. Is there a way to mimic a more traditional session behaviour by refreshing the JWT in the background? Even if I was on board with the security implications of pushing the session duration to “1 month”, this still would mean an abrupt session cut-off and a forced re-log in for users at a possible inconvenient time.
Thanks for your insights,