V2 cookies are huge

[piec]

Hi,

Thank you for your work on v2.
In my use case I need to call userinfo and the v2 api makes it really simple. In v1 I have to keep around users' tokenset with express-session for example.

The issue I have is the size of the appSession cookies (plural because they are chunked in several cookies).

A bit more than 4k in my case, is it due to my setup? (I guess a tokenset is stored in the cookies which explains the simplified userinfo api). V1 appSession cookies are ~500 bytes.
For each request+response from the browser to the api the cookies are sent as part of the request and updated cookies are sent from the api.
I think I wouldn't have noticed immediately but the default configuration of nginx (used as reverse proxy in front of the api) doesn't let these large headers go through: (due to the cookie size I think)

[error] 27#27: *897 upstream sent too big header while reading response header from upstream, client: 172.18.0.1, server: , request: "POST /api/auth/callback HTTP/1.1", upstream: "http://172.18.0.5:3001/api/auth/callback"

nginx can be configured to allow this using for example:

proxy_buffer_size          128k;
proxy_buffers              4 256k;
proxy_busy_buffers_size    256k;

What do you think about it?
The tokenset has to be stored somewhere but it's not always needed for very simple usecases right?

[adamjmcgrath]

Hi @piec - thanks for raising this

In v2 we wanted to simplify the advice on getting/persisting access tokens. So we went for storing them, along with ID tokens, in the cookie session by default.

The tradeoff we made was that now the cookies can get larger, and so we added cookie chunking in to avoid hitting browser limits on individual cookie size (~4kb)

If I run the sample app with an Auth0 account and set authorizationParams.response_type 'code' (So I can get an AT to access /userinfo), my token set looks like:

{
	"id_token": "[a JWT ~1,900 chars long]",
	"access_token": "An opaque token ~30 chars long",
	"token_type": "Bearer",
	"expires_at": 1601551231
}

Which serializes (encrypted) to about 2.8kb. If my access token was a JWT as well, or I had a bunch more claims in my ID token this size would increase, perhaps to slightly over 4kb, so in the case of nginx I would have to update my server configuration to allow for this.

The tokenset has to be stored somewhere but it's not always needed for very simple usecases right?

Assuming you want to persist a user's logged in state and access an api, then you need to persist the ID Token and Access Token.

As an aside - we're planning to add a feature to allow the user to provide an express-session compatible storage option, which would allow you to drop in a different session storage mechanism, which would make the SDK act more like v1, but with the simplicity benefits of v2.

We're also planning on adding extensibility points into the library as hooks - so you can have more fine grained control over what is stored in the session.

[piec]

Thanks for this detailed answer, I understand the tradeoff.
I'll try to tune my authorization parameters to reduce the token set size and get smaller cookies.

Adding the option to use an external store (or not storing at all) and external hooks is great :)

[adamjmcgrath]

Hey @piec - just to let you know that we've released 2.3.0-beta.0 with support for custom session stores.

See the example snippet: https://github.com/auth0/express-openid-connect/blob/2.3-beta/EXAMPLES.md#9-use-a-custom-session-store and example app: https://github.com/auth0/express-openid-connect/blob/2.3-beta/examples/custom-session-store.js

You can try it out by installing the beta from npm npm install express-openid-connect@beta - let me know if you try it out, I'd love to get some feedback on it before I release it proper.

[piec]

Thank you @adamjmcgrath I will take a look at it and try

[awacode21]

Experiencing the same, anything new on this?