Skip to content
This repository has been archived by the owner on Feb 24, 2018. It is now read-only.

Cookie Storage Limits on Safari #688

Open
hilkeheremans opened this issue Feb 15, 2018 · 1 comment
Open

Cookie Storage Limits on Safari #688

hilkeheremans opened this issue Feb 15, 2018 · 1 comment

Comments

@hilkeheremans
Copy link

For a project we are currently working on, we are using cookie storage to enable single-sign on across various subdomains (eg site1.domainname.com, site2.domainname.com).

Testing has shown that the tokens that Cognito generates are rather large. Especially when device tracking is enabled, the tokens that require storage will easily surpass the per-domain cookie limits of some browsers, most notably Safari, which, even in its latest iterations, still has a specific limit of about +- 5090 bytes per domain (= the sum of all cookie sizes on a particular domain cannot exceed 5090 bytes). Once that limit is exceeded, the entire domain becomes inaccessible from Safari, with a cryptic kCFErrorDomainCFNetwork error 303. The only fix we are aware of at that point is to fully clear the cookies.

To provide some data on base token size, for the three tokens issues by Cognito:

accessToken: 1077 bytes
idToken: 1745 bytes
refreshToken: 1852 bytes

TOTAL: 4674 bytes

Clearly it's quite easy to bump into the domain-level cookie limit on Safari, especially if device tracking is enabled. Even with device tracking disabled, our ability to use other packages, modules, plugins, ... on any subdomain is now limited, since they might also have a need to set cookies.

A cursory examination of the token contents indicates that some tokens may be larger than they strictly need to be. For example, the idToken appears to contain full user information, including custom fields. I can imagine situations where, if a Cognito User Pool has lots of custom attributes set to their maximum limit, token sizes would quickly become prohibitively large.

I don't have an immediate solution to propose, except perhaps to allow blacklisting/whitelisting of properties inside the idtoken. This way, the admin has control over what fields should be included in the token itself.

Any other suggestions?

@itrestian
Copy link
Contributor

One options is to use the pre token generation trigger feature that allows you to override token claims: https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-lambda-trigger-examples.html

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants