Set-Cookie header is ignored due to size limit after the Kibana upgrade to 1.10.1

[arnitolog]

OpenID integration stopped working after the upgarde of Kibana to version 1.10.1.
Checking the headers I found that the set-cookie header is ignored due to the size limit.
Here is a message from the browser dev tools:
Set-Cookie header is ignored in response from url: https://logs-test.us.dev.kube.company.com/auth/openid/login?state=abKJ_B2F8UGxIw7HWbhWIp&code=a950100f-19d1-4bb6-8b50-0557362be14b.1e86c530-392c-4bd2-81fa-ca31a25db5f2.208d33ca-1735-423c-8075-8860fa0a8c34. Cookie length should be less than or equal to 4096

[zengyan-amazon]

Since this problem looks specific to OIDC, as the JWT token might be very large we might provide an config to make the refresh token optional.

A more decent solution might be encode the cookie with gzip or other compression encoding to reduce the overall cookie size, before sending it back to browser. but it requires encoding/decoding at server side, and potentially impact server side performance. And this optimization also requires bigger effort to refactor the cookie handling code.

[zengyan-amazon]

@arnitolog do you have an idea of how long your JWT tokens are?

[arnitolog]

@zengyan-amazon it is 11769 characters.

[zengyan-amazon]

@arnitolog if the id_token by itself is already more than 11k characters, and it worke with old versions like ODFE 1.9, maybe hapi/iron, the Kibana cookie encryption library has done some sort of encoding/compression when encrypting the cookie.

We need to look deeper into it and see how to optimize it to support big JWT token case.

[arnitolog]

thank you @zengyan-amazon. Meantime we will try to decrease the size of our JWT token

[sushant-pradhan-tm]

@zengyan-amazon is there some update on this issue? Its kind of a blocker

[zengyan-amazon]

@arnitolog @sushant-pradhan We tried to compress the JWT token, but it turned out that the compress ratio is not ideal.

The problem is we are using id_token as the bearer token, which includes user profile ( if you request profile scope ), that can be very large.

In your case, is your accessToken also a JWT token? if so do you know how long is your access token? If your access_token is much smaller than id_token, maybe we can consider to use access_token with custom claims to replace id_token to mitigate this issue

[arnitolog]

@zengyan-amazon I already solved this issue. I found that we sent all available groups from Keycloak in JWT token. But for ODFE we need only 1 (it can be a user role or admin role), So, I created a custom mapping in keycloak client to keep only this role and filter out everything else. And that did the trick.

[zengyan-amazon]

@arnitolog Thanks for your update.

@sushant-pradhan can you share some detail of your use case? like how long are your JWT tokens, and whether you are able to reduce the size of your token from IDP?

[mrhorvath]

We are having the same issue, though we're going against an adfs openid server. The cookie size is over 6000 characters and has been preventing us from being able to upgrade past 1.9.0. We end up seeing the set-cookie fail and get redirected back to the idp until the max redirects gets hit. Really looking forward to a fix, and I'm willing to help by answering any questions you might have about our setup.

[zengyan-amazon]

@mrhorvath thanks!

Can you share

• which OIDC IDP you are using? Does it support custom claims in access token?
• what scopes do you configured in opendistro_security.openid.scope.

and it will be very helpful if you can share the length of your id_token and access_token in your case. We are considering to allow customer use access_token (usually much smaller than id_token) with custom claim as the bearer token to solve this issue.

[sushant-pradhan-tm]

@arnitolog Thanks for your update.

@sushant-pradhan can you share some detail of your use case? like how long are your JWT tokens, and whether you are able to reduce the size of your token from IDP?

@zengyan-amazon apologies for delayed response. My setup is AzureAD tenant. I checked my access_token is about 2270 characters (1481 characters after decoding) and is not a a token with roles from IDP: so this can't be used. id_token is 1392 characters encoded (and 820 characters after decoding jwt.io) and has role info. And since I am part of 5 roles for the Azure application, it comes back with those 5 roles. 5 roles is very low, it can sometimes be pretty big (and used to work pre upgrade). Please let me know if you need more data

I am wondering if the new feature to merge id_token and refresh_token as described here be made a configurable parameter? This way, we can have a capability to turn it off and at-least have the login enabled. For now our users are totally locked out