bug: NodeJS `encrypt` function dramtically increases size of cookie and can lead to it being discarded by the browser when over ~4000 bytes

[jonsamwell]

Describe the bug

After logging in, the idToken, accessToken, and expiry information are encrypted and sent to the browser in a cookie. Before encryption, this data typically amounts to around 2000 bytes, although the exact size can vary. In this example, the user's data includes email, profile scopes, and roles across a few organizations.

After encryption, the size of the cookie can increase significantly, approaching the 4096-byte browser cookie soft limit. Beyond this limit, browsers may start to discard the cookie, leading to potential issues. This behavior was discovered during development in Svelte, where an error is thrown when this limit is exceeded. For more details, see the relevant code in the Svelte GitHub repository.

Expected behavior

The size of the cookie should be controlled to stay within the accepted limits that all modern browsers will accept. Maintaining a smaller cookie size ensures faster transfer of the cookie on each request to the issuing server. This optimization enhances performance and prevents potential issues related to exceeding the cookie size limit.

How to reproduce?

Use any JavaScript frontend with the appropriate Logto frontend package. Log in as a user who belongs to multiple organizations, each with several roles. Include the email and profile scopes in the login request. Specify a resource or two to ensure the accessToken is retrieved and populated. Observe the size of the cookie after encryption and storage.

This setup results in a comprehensive and realistic identity/access token. After encryption, the size of the cookie will significantly increase, potentially approaching or exceeding browser limits.

There are a few options we could try to address the issue of large cookie sizes (I am happy to do a PR for whichever route is deemed best):

1. Split the Cookie into Chunks Over a Certain Size

   • Pros
     • The size can be controlled
   • Cons
     • Increased complexity when reading and writing cookies.
     • Decreased performance due to the need for encryption/decryption of each cookie chunk

2. Compress the Plain Text Before Encryption (e.g., with gzip/brotli)

• Pros
  • The size can be reduced easily
• Cons
  • Slight decrease in performance, but the slow part is the encryption process.

3. Compress the Encrypted Cookie (e.g., with gzip/brotli)

• Pros
  • The size can be reduced easily and may lead to a further size reduction against option 2
• Cons
  • Slight decrease in performance, but the slow part is the encryption process in any case.

Context

• [x] Logto Cloud (using Svelte frontend package)
• [ ] Self-hosted, Logto version =
  • [ ] Container (Docker image)
  • [ ] Raw Node.js