Expiring and refreshing Cloudflare Acces JWT (SSO)


I am trying to set up Cloudflare Access in front of two web apps:

  • myserver.com/wordpress (Wordpress)
  • myserver.com/express (Express)

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_Authorization cookie from both myserver.com and custom.cloudflareaccess.com
  • B - visiting custom.cloudflareaccess.com
  • 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,