Help! JWT Token Error on production server.

Bruce Williams asked on May 13, 2022 19:52


Our dev team has looked at the following post to see if there is any misconfiguration with our application's setup. Unfortunately, I'm having a hard time reproducing this issue consistently as it seems to be cache-related or timeout value from the cookie. Still, after the site has been up for over a few mins to a couple of hours we are presented with the following:

Image Text

The server the site is sitting on is locked down and behind a bastion, for remote access, and only port 80 and 443 are open. A valid SSL is applied to the domain. The site is not setup for web farm and is a single domain site ( &

Since we aren't using the web farm option we don't have an option to clear the restart the web farm, which according to documentation it seems is now the only way to clear the front-end of the site's cache and the clear cache button only clears the admin's. As a result, we have to go into IIS and recycle the app pool in order for a new JWT token to be provided. Once that is done the site will work as normal for like I said about a few mins to possibly a few hours before we hit this again.

Anyone have any other suggestions for correcting this?

Recent Answers

Brenden Kehren answered on May 16, 2022 03:18

If you're using version 12 or 13 and using MVC, the web farm option should be enabled for you by default. You may need to enable that feature depending on what version you're running in. Web farms should be enabled when using MVC, it should NOT be turned off, no matter if you're using a physical web farm or not.

0 votesVote for this answer Mark as a Correct answer

Juraj Ondrus answered on May 17, 2022 05:50

Allow me to share some information from an article one of our senior specialists is currently in the process of writing about this error message, applicable for Kentico Xperience 13:

Administration and Live site are currently two separate applications (unlike in Portal Engine, where administration and Live site were one application), each of them has its own life cycle and authentication.
In some cases, this strict separation does not apply, specifically to PageBuilder and FormBuilder. In both cases, a live site is used to render the administrative UI using our endpoints (registered under*) and scripts (*) on the live site. The reason why we approached this solution is prosaic - both builders have to run in the context of the Live site.

Each application handles authentication individually (administration uses ASP.NET membership and live site OWIN authentication). In case we render any of the builders or page preview in the administration, we already know that it runs in the context of a live site, but they lacked information about the currently logged in user in the administration. We decided to solve this problem by storing this information in a cookie.

So how the authentication of the Page builder frame for display purposes in administration actually works:

The administration application sends a request with a generated token to the live site system endpoint:*, live site verifies the validity of the token and issues a new token, where there is an information about the currently logged in user and saves this newly created token into the cookie under the name CMSVirtualContextIdentity.

When authentication is performed in Page builder, Page builder authenticates against this information in the cookie.

There are some issue with blocking 3rd party cookies: modern browsers try to prevent tracking of users, especially by blocking 3rd party cookies. Most browsers by default block only tracking of cookies. This means that our authentication cookie should work. But users can change this setting and therefore breaking the page builder's authentication.

At the same time, for example, Chrome blocks 3rd-party cookies also in its incognito mode. Safari uses its own heuristics.

There are multiple possible setups:

1. with the same domains:

The administration and live site applications use the same domain. The CMSVirtualContextIdentity cookie, which authenticates the live site in the page builder, is stored in the same cookie domain space as the administration. There is no 3rd-party cookie blocking applied, the page builder iframe has access to the cookie. For example:

Administration: localhost/admin Live site: localhost/site


  • CMSVirtualContextIdentityis accessible from the page builder iframe
  • this setup does not require HTTPS so it can be used in a dev environment

2 with the different domains

The administration and live site applications use different domains. There must be some additional steps taken in order to store the CMSVirtualContextIdentity cookie in the page builder frame. For example:

Administration: http(s):// Live site:

and therefore:

A) Proper domain setup

Live site must run on HTTPS because of the SameSite policy. SameSite mode is configured correctly Browser cannot block 3rd-party cookies

B) Local development setup (ASP.NET Core only)

The page builder authentication can proceed without the CMSVirtualContextIdentityauthentication cookie. Kentico Xperience 13 is able to pass the authenticated user in a URL itself.

Although we are able to carry the authenticated user in the URL, it is not as secure as to store it in the cookie. Therefore we allow this simplification only for loopback domains in your DEV environment.

Kentico Xperience 13 leverages this simplification in the initial setup of the Xperience Dancing Goat Core sample site and the Blank Core site. Therefore the installed sites do not have to deal with various problems with cookies or invalid/self-signed certificates. How it works: ASP.NET Core sites can disable the cookie authentication in the dev environment via the DisableVirtualContextSecurityForLocalhostservice.

Once configured, the user information will be passed in all page builder requests in their URLs.

I hope it helps and gives you the idea how it works.

0 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.