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,



I believe I figured out a solution for your second question.

1 Like

Thanks for your suggestion! I ended up going another route but this is interesting to know nevertheless, thanks for sharing.


Hey @mlbrgl I actually have exactly same questions as you wrote in initial post, any learnings from your side? Did you solve the issues mentioned?


hey @dusan, I slightly modified my setup since my original post.

The biggest shift was to not try and rely on JWT for session management. Sessions are handled by each individual app.

Cloudflare only protects the login pages, and only keeps track of the authorization for a short time after the end of the login flow.

On the other hand, the web apps (Express or Wordpress) will persist their individual sessions for a longer time once logged in. This means users will go through the login flow again if they ever accessed the login pages directly.

Ultimately, it is then the responsibility of each app to redirect to the login pages so Cloudflare can take over. Ideally, Cloudflare would have been in front of the entire apps but I couldn’t make it happen without impacting the day-to-day app workflow.