What determines session cookie size?

[shawnchapla-8451]

We using an OSS plugin for Kong OSS v3.1 and using the cookie session scheme provided by the version of lua-resty-session that comes with that version of Kong. My question is when the plugin is caching the JWT in the cookie, what affects the size of that cookie? For example, in testing, we found that an example JWT size of just under 1,500 characters is resulting in a session cookie size of more than 8,000 bytes.

I assume the JWT is encrypted and encoded before being written as a cookie, but are there any settings for this module which can control that? Specifically, we're looking to make it smaller if possible because it appears an intermediary proxy is rejecting the response from Kong with the total response headers of the size resulting from this cookie. We believe the limit for the response headers in the proxy is 8K, and this example results in a response with total headers size greater than that.

[bungle]

@shawnchapla-8451 it looks like it is using resty.openidc (https://github.com/zmartzone/lua-resty-openidc).

It looks to have this parameter: session_contents = {id_token=true}

-- Whitelist of session content to enable. This can be used to reduce the session size.
-- When not set everything will be included in the session.
-- Available are:
-- id_token, enc_id_token, user, access_token (includes refresh token)

So by default it includes everything. several tokens (id, access, refresh), userinfo perhaps etc.

In that old session library you may also use session_compressor=zlib: https://github.com/bungle/lua-resty-session/tree/v3.10#pluggable-compressors

[shawnchapla-8451]

@bungle thanks, will look into the suggested setting for the openidc module.

[bungle]

@shawnchapla-8451 you could also try to get tokens smaller on IDP, e.g. less claims. perhaps using different crypto that generates smaller signatures, perhaps utilize opaque tokens instead of jwt tokens in e.g. refresh token etc.

Or you could just map session to your own application managed identity and fully detach from OIDC after login.