Description
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?