Current session cookies are sometimes bloated (hence the cookie splitting issue). With the current implementation, there's the potential for access/id/refresh tokens to have 3 levels of base64 encoding bloat (adding 33% (my math right?) size increase each time) when 1 is potentially needed for the final cookie.

Possible Solution

I have a branch where I've implemented a --session-store-compression feature that follows the following logic:

• Opportunistically base64 decode the 3 tokens (if they can be)
• Store the encoded session in MessagePack (instead of JSON since it allows binary data)
• (Debatable - Currently implemented) LZ4 compress the MessagePack encoded session
• Encrypt the whole payload now (rather than for each sub field like before with a base64 encoding to be a valid string for JSON).
• Wrap message in new lightweight SessionEnvelop struct (allows easier detection of changed session cookie types & legacy coming in).
• Now Base64 the session for the cookie with encryption.SignedValue. This is the only Base64 encoding now.

Some rough numbers after testing various sessions with a generic OIDC provider:
Current _oauth2_proxy cookie size: ~5000 bytes
Compressed: ~2700 bytes
Compressed (without LZ4 compression, just base64 tricks + messagePack): ~3500 bytes

Related: I didn't touch legacy behavior, but moving to a MessagePack encoding and encrypting the whole message (and not base64 encoding the encrypted bytes) can result in 1 less base64 encoding bloat from current behavior.

Your Environment

• Version used: master