Relay Set-Cookie headers to clients when AuthService returns them on a 200 response.

[fabiosimeoni]

Emissary automatically forwards Set-Cookie headers to upstream services when an AuthService returns them on a 200 response.

It'd be helpful to clarify the rationale for adding a response header like Set-Cookie to a request. It'd be far more helpful to relay Set-Cookie headers back to the client, adding it to the responses of upstream services. This is key to implement token refresh policies in the sort of workflows that OAuth/OIDC standardises, including the rotation schemes on refresh tokens upon which features like sliding sessions can be mimicked.

Envoy appears to support this now with his allowed_client_headers_on_success (cf. https://github.com/envoyproxy/envoy/pull/14514) would it be possible to lift that up, or even to use it internally for Set-Cookie?

I am aware that the full distribution offers an OAuthFilter, but the documentation there doesn't refer to the possibility of implementing token refresh strategies. Even if it did, there's value in supporting custom authentication workflows (think token swapping, custom checks, etc). And there's of course value in sticking with your lighter distribution, which is excellent, and where the OAuthFilter wouldn't be available anyway.

As it stands now, implementing token refresh schemes via the AuthService requires help from the upstream services, which must move Set-Cookie headers from requests to responses on each request. Even when this is easily done with interception mechanisms at service level, it's a task that may well fall on all upstream services. Mostly, the task runs counter-current the whole idea of "terminating" authentication at the edge, which is one of the strongest driver for a gateway. It seems to ma that the upstream services should just find trustable evidence of authentication in the requests, not help out the gateway implementing authentication schemes.

[alfrye]

@fabiosimeoni I have a similar issue when using the Authservice in emissary-ingress to set a response cookie but I do not see the set-cookie header in my upstream service. I am curious if you are able to see the cookie in the your upstream services please refer to my issue at https://github.com/emissary-ingress/emissary/issues/4381

Thanks in advance for any insight to my issue

[fabiosimeoni]

hey @alfrye, it was a while back.

I still see this in my AuthService config of the time:

looks like I bypassed the whole thing, carried the cookie in a custom header, intercept it at the upstream service to then bounce it back to clients in the standard Set-Cookie.

I am not in a position to confirm directly Set-Cookie is still sent out in requests, sorry. But the whole idea of setting it on a request seemed weird to me from the get go...

good luck!