Options to not send oauth2-proxy specific cookies to upstreams

[segaura]

Oauth2-proxy cookies, especially in cookie storage mode, can be big in size, think of a access, refresh and id token combination stored inside cookies, for instance.

Expected Behavior

Oauth2-proxy could accept a new configuration parameter which allows to remove its own cookies from requests to be sent to upstreams.

Current Behavior

Currently there are solutions in place to stip entire headers, but the Cookie header mixes oauth2-proxy own cookies with ones for other destinations.
So while my spring-boot upstream needs only its "JSESSIONID" cookie, it now receives also _oauth2_proxy_0 and _oauth2_proxy_1 which are more than 6KB together.

Possible Solution

In headers.go, along with others header treatment, which already take care of stripping some of them and removing configured informations, it should be possible to split the Cookie content and remove oauth2-proxy specific cookies from it.

Context

My main concern regards performance, because in cookie storage mode, cookie size is typically 6KB in my context.
We find some of our Tomcat-based upstreams rejecting requests because they exceeded the 8KB default limit for headers size.

Your Environment

• Version used:

7.4.0

[JoelSpeed]

I would recommend, if the cookies are causing issues, to try a server side session storage, this will greatly reduce the size of the cookie being sent to the upstream.

Right now, the only implementation we have is redis, but I'm open to PRs for other server side session stores based on the same interface

[segaura]

Sure, we understand that with server side storage, redis, jdbc or something else the problem is not present.

My point is that now with cookie storage, oauth2-proxy encrypted cookies are travelling two sections:

• the first from the browser to oauth2-proxy, which is necessary
• the second, from oauth2-proxy to any upstream, which is not necessary, and this will not change because upstreams can't decrypt them

That holds also for server side storage, it is not necessary to forward the small-redis-key-cookie to upstream.

Are you open to implement or accept a PR implementing a switch to prevent this cookie forwarding to upstreams?

[JoelSpeed]

I'm open to including an option for this sure, would need someone to raise a PR for it

[github-actions]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.

[segaura]

No bot, please don't close this, we are considering sending a PR to implement it.

[github-actions]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.

[dorinclisu]

Still valid