How to reduce Keycloak cookie size?

[angelod1as]

We have a Keycloak setup in one of our company’s project and we’re hitting an issue I couldn’t find an answer for.

We’re hitting a cookie size limit and we need to reduce the cookies sizes. The issue is that the biggest (by far) cookie we have is Keycloak tokens (around 6kb).

An example token:

token: {
    email: 'test@test.com',
    sub: [a UUID],
    user: {
      id: [a UUID],
      email: 'test@test.com',
      firstName: 'Test',
      lastName: 'Test',
      street: 'Test',
      houseNumber: '1',
      addressAddition: '',
      postalCode: '1255',
      city: 'Test',
      country: 'Deutschland',
      phoneNumber: '11122333',
      customerId: '187080035T',
      providerUserId: [a UUID],
      providerId: 'credentials'
    },
    idToken: [A 1210 characters string],
    accessToken: [A 2091 characters string]
    refreshToken: [A 778 characters string],
    expires_at: 1710502776,
    iat: 1710502476,
    exp: 1710502776,
    jti: [a UUID],
  }

Initially we thought of removing all the personal information but the IDs from the cookie but I only saw a reduction of 500 bytes — and we’d need a lot of new code to access user data from our front-end.

We’d need to reduce (somehow) the ID sizes, or at least understand better why we can’t reduce them — so we can explain this properly to management and DevOps.

Can you help me with this issue?

[embesozzi]

Having issues in relation to the cookie or HTTP header size is a “common” issue in IdPs. Nevertheless, I don’t understand the token example (because that is not a token) that you are posting, but I don’t want to go down that rabbit hole.
Here are some common rules to follow:

1. Don’t put too many claims in the token
2. Use the user-info endpoint to get additional data. This approach does not imply adding a lot of code because nearly every single OIDC certified library supports it by just calling a library method.
3. It’s common to change the max-http-request-header-size in the backend when you move to the authz cases to avoid certain issues
4. Then you have a more complex approach if you have a proxy / gateway in between that helps with cookie splitting or removing unnecessary information to the backend.
5. I have never tried it in Keycloak (I’ve used it in other IdPs), but you can use the opaque token type, but I think it’s too much.

[dasniko]

@embesozzi

5. I have never tried it in Keycloak (I’ve used it in other IdPs), but you can use the opaque token type, but I think it’s too much.

AFAIK Keycloak does not support opaque tokens.
Starting KC24 Keycloak supports a “lightweight” JWT, but it’s still a JWT.

[embesozzi]

Oops, I thought it was supported. Thanks for the clarification.

[angelod1as]

I wasn’t responsible for implementing this and I’m quite lost on it, honestly. I ask for patience, please.

You say that what I posted is not a token. How should I call it, then? That’s what is in the cookie.

As I wrote, reducing user data in the cookie does not solve our problem — reduces 500 bytes of the 6kb cookie.

So, I assume that this has no solution other than increasing the max-http-request-header-size in the backend, correct?

[dasniko]

@angelod1as

You say that what I posted is not a token. How should I call it, then? That’s what is in the cookie.

Call it “Cookie content”.
This seems to be a cookie from your application, it’s not a Keycloak cookie. And it’s not a token.
The cookie contains some data similar to various tokens, but it is not a token.

[angelod1as]

Yeah, I apparently don’t know what I’m talking about here. I’ll ask people that might know more to take a look here and clarify stuff.

[Biju]

Actually you’re right it’s not a Keycloak cookie. We integrated Keycloak in to our NextJS application. So as usual we use NextAuth to handle our authentication purposes. So it is a NextAuth session cookie (see image)

This cookie contains some tokens that is coming as part of Keycloak integration like sessionToken, accessToken and refreshToken and since these tokens are big it makes the accumulated cookie size bigger (around 6kb) and as you can see in the screenshot the browser itself splitted it in to two cookies because of the size issue. What we were wondering is, is there any possibility in Keycloak to reduce the size of the JWT token, like using some different signing algorithm or reducing the amount of information send with these tokens, something like that? Or is there any other approach that we are unaware about?

[jean.silga]

A first iteration would be to look at the various objects of your cookie and remove all duplicated attributes. For instance, the email address is included by default in the id token & access token and you also have it twice is you cookie object.
Other attributes to consider are the firstName, lastName, expires_at, iat attributes, which are in the tokens by default. Address and contact related attributes must be considred as well.
Try as much as possible to have each piece of information only once in your “cookie”, be it in the user object or in one of the tokens.
You can always call the userinfo endpoint to retrieve more information at any point in your application if needed.

[Biju]

Is it possible to avoid some information from jwt token. I mean is there any settings in Keycloak that does it? About user object in the cookie, it’s actually the one we added to it. It is possible from our side to remove unnecessary info from that object that is added to the cookie, but from the sessionToken and accessToken, is it possible to remove some repeating info via Keycloak configuration?

[jean.silga]

@Biju

is it possible to remove some repeating info via Keycloak configuration?

Yes the token’s payload is configurable. The client scopes and their mappers define what information will be included in the token. As a test, set all client scopes of your client to optional and see what happens to the payload of your token.

You can choose to have in the token only the information you need and that will reduce its size.
Once you are sure you don’t need some on the client scopes, you could remove them from your client to make sure that no one will able to request them.

[Biju]

I tried this and it had no impact on the cookie size. I set almost all of them to optional and still the cookie had the same size as before. I don’t know if I am missing something here

[MatheusFerreiradeOli]

Hi, I am facing the same issue with next-auth coockies size. Is there any other workaround? I’ve also tried the Optional idea but that did not reduce the coockie size. Any new ideas?

I am using “next-auth”: “^4.24.7”,`