Javascript set cookie max size is exceeded due to a large JWT token

Question

I am using JWT token for the authentication and since the server is stateless, the client (Javascript app) uses cookies to store the JWT token, read the token every time from cookies and set the authorization header accordingly on any call to the server. The issue I am facing is the token can become larger than 4KB and this is causing a failure on the javascript part. Apparently, Javascript has a limitation of 4KB for the cookie size. Therefore, this is causing an issue.

Set-Cookie header is ignored in response from url: xxxxx. Cookie length should be less than or equal to 4096 characters

My question is what can I do to address the cookie limitation from the javascript point of view? Is that even a right thing to set the JWT token in the cookie? I would imaging having a JWT token larger than 4KB can happen with some applications. What would be the alternative (and yet secure) approach to handle it in a stateless way and manage the javascript limitation?

Answer 1

Is that even a right thing to set the JWT token in the cookie?

If you are using an httponly cookie then yes. It is safe, a lot safer than using Web Storage(localStorage or sessionStorage). Actually storing your JWT token in localStorage or sessionStorage allows an XSS attacker to steal users token and send them to his/her own server, On the other hand since httponly cookie cannot be accessed from javascript running on browsers, then in case of an XSS attack, the attacker won't have access to the user's JWT.

If you set JWT in cookie you don't have to set the token in Authorization header on every request since the browser will automatically send it for you to the server which has set the cookie for you.

Keep in mind that as I mentioned, saving JWT in cookie means that server automatically will send the JWT for you to the server, which means it makes you vulnerable against CSRF attacks(if you put the JWT in localStorage or sessionStorage you won't be vulnerable to CSRF attack but as I said you would be vulnerable against XSS attacks). So you should prevent CSRF attacks by using CSRF tokens in your application.

What would be the alternative (and yet secure) approach to handle it in a stateless way and manage the javascript limitation?

As I said, put your JWT in an httponly cookie and in order to bypass the cookie max size limitation enforced by browsers, You can chunk your cookies once they reach the 4kb limit in size. This is what some popular libraries do e.g. next-auth and dotnet

it works like this: Once your cookies exceeds the 4kb size. You will chunk them and prefix or postfix them with numbers so you know the order in which they should be merged later. For instance if you are trying to set a JWT whose size is 130kb in a cookie named accessToken then since 130/40 = 3.25 you at least need 4 cookies named accessToken_1 and accessToken_2 and accessToken_3 and accessToken_4

Note that you should try to avoid large cookies since larger cookie means, more data being sent over the internet which means slower request/response.

Answer 2

You could store the token in the sessionStorage or localStorage and append the token in all requests in the Authentication header. You could implement Bearer Authentication in your application.

You could save data in the sessionStorage or localStorage upto 5 MB And these methods are more secure than cookie.

Session Storage:

The sessionStorage property accesses a session Storage object for the current origin. sessionStorage is similar to localStorage; the difference is that while data in localStorage doesn't expire, data in sessionStorage is cleared when the page session ends.

1. A page session lasts as long as the browser is open, and survives over page reloads and restores.

2. Opening a page in a new tab or window creates a new session with the value of the top-level browsing context, which differs from how session cookies work.

3. Opening multiple tabs/windows with the same URL creates sessionStorage for each tab/window. Closing a tab/window ends the session and clears objects in sessionStorage

Local Storage:

The read-only localStorage property allows you to access a Storage object for the Document's origin; the stored data is saved across browser sessions. localStorage is similar to sessionStorage, except that while data stored in localStorage has no expiration time, data stored in sessionStorage gets cleared when the page session ends — that is, when the page is closed.

Answer 3

You can use both localStorage and sessionStorage, for clear understanding of both kindly see the here! answer.