Cookie Storage sizes are too large

[guanzo]

Relevant issue: amazon-archives/amazon-cognito-identity-js#688

The benefit of cookie storage is that it enables single sign on for a root domain and all subdomains, it's a great feature! However there are some drawbacks concerning storage size.

When I log in as User A, Cognito creates cookies with a total size of ~4.5k bytes. The largest cookies are the refreshToken, idToken, and accessToken. This size is over the limit that Safari sets per domain: 4k bytes. When I log in again as User B, without signing out User A, Cognito will create another set of cookies, increasing the total size to 10k bytes for a single domain. This means 10k bytes are sent for every single request set to that domain.

I think Cognito should strive to keep the total cookie size to a minimum. Regarding my example, what if when signing in as User B, Cognito deleted all cookies related to User A? Or simply, Cognito deletes all cookies unrelated to User B?

If not, is there a way to do this in my code? That is, during Sign In, can I delete all cookies unrelated to the current authenticated user?

[hilkeheremans]

The main thing to remember here is that Cognito tries to include all user data in the identity token. Especially if you include custom data, this will quickly start to add up as you add lots of data.

Here's a trick: if you want to reduce token size, the easiest way to do so is to evaluate which information you really need in the identity token, and then use claimsToSuppress on a Pre Token Generation Lambda (see https://docs.amazonaws.cn/en_us/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html) to not include fields you don't really need. This can make a huge difference.

I would add some example code here if I still had it, but I built this for a confidential project which I am no longer involved with, so I deleted the code afterwards. Still, you should be able to figure it out -- if not, throw a shout in here.

[hilkeheremans]

Second thing: to avoid the issue in the first place, you should be able to log out the old user which should also delete those cookies. I don't recall if this kind of logout happened automatically in the old pre-Amplify cognito library if it detected a new user, or if I coded something manually to do that. I certainly don't know how one would go about this in Amplify.

Good luck!

[guanzo]

Thanks @hilkeheremans, I'll give the Lambda solution a try.

[wcoppens]

@hilkeheremans Did you ever get the total cookie size below 4kb? Because even when we suppress all claims which we are allowed to suppress according the documentation, we still exceed the 4kb with +/- 200 bytes.

[Nickman87]

We got around this by creating a "HybridStorage" which only stores essential cookies LastAuthUser, refreshToken and deviceKey in a cookie (to work cross domain) and the other data in localstorage, thus keeping cookies to a minimum.

Ths does however pose issues when trying to share logins from identity providers over multiple domains as you cannot refresh them with Cognito themselves and need to redirect to the external providers if you want to do this... We just keep all cookies when somebody uses an identity provider for now.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. Please open a new issue if are still encountering problems.

[kushmangal]

Any update on this issue? Large cookie storage size breaks the system due to limitations in request header size.

[dallen4]

Also looking for updates on this issue. We store only a few attributes within a user in Cognito and still get performance issues. I think it's disappointing this issue (and those preceding it that contained nearly identical experiences) received so little attention and most people are told to implement a custom pre-token generation lambda trigger. Cookies generated by an auth system as widely used as Cognito should not exceed browser storage limits that can break websites. It should at least be better detailed in documentation as practices to avoid and mitigate these issues if the library doesn't see browser compatibility as crucial.

[damjanvucina]

Here's a working example of such lambda.

// should be set up in cognito triggers as a Pre Token Generation trigger

exports.handler = (event, context, callback) => {
    event.response = {
        "claimsOverrideDetails": {
            "claimsToSuppress": ["email", "fullName", "whatever"]
        }
    };

    callback(null, event);
};

[thomaswr]

This is a major issue for us.

Cognito amounts to almost 5K of cookies with the cookieStorage implementation, while many webservers define 8K as the default maximum.

Are there any alternative Implementations besides cookieStorage and localStorage?
Why are the cookie names alone that long? Can it be renamed?
Are all cookies required?
What's the official stance towards this issue?

Thank you

[ryanvade]

#5330 (comment)

[github-actions]

This issue has been automatically locked since there hasn't been any recent activity after it was closed. Please open a new issue for related bugs.

Looking for a help forum? We recommend joining the Amplify Community Discord server *-help channels or Discussions for those types of questions.