Consider using direct JWE encryption of the OIDC session cookie

[sberyozkin]

Description

Now that the OIDC session cookie is encrypted, in some cases users keep getting warning the session cookie size is more than 4K, with several options proposed how to make the session cookie size less, including turning off the encryption.

Encryption increases the session cookie size, however the way it is done it is probably increased more than really necessary.
Right now, the content encryption key is generated and the configured or derived encryption key encrypts that content encryption key which then encrypts the cookie.

So the generated content encryption key, in the base64 URL format, is added to the overall encoded cipher text sequence and it can be 45 or so characters.

Direct encryption is a typical encryption where the configured secret key is used to encrypt the text directly, without a generated content encryption key indirection.

In fact, this is exactly what Auth0 also does for its access tokens which have no audiences.

Implementation ideas

If the configured/derived encryption key is at least 16 characters then use a dir (direct) JWE encryption.
Also, log the session cookie size if it is larger than 4K

[quarkus-bot]

/cc @pedroigor (oidc)

[sberyozkin]

That said, may be it is not worth is as extra 45 chars won't make a difference if the encrypted sequence is for example 5K.

May be, when the cookie size is more than 4K, then it can be automatically split into chunks as suggested in the first comment at https://stackoverflow.com/questions/77660268/quarkus-oidc-session-cookie-limit (ASP.NET), it can be quite messy though

[sberyozkin]

Dir encryption would def be fast though as it skips the generation and encryption of the content encryption key. So it should be worth exploring after all