I'm not sure if this is helpful. In my case, the same issue occured since the response cookie size was larger than 4096 bytes. To reduce the size, I reduced the number of claims on OIDC.

The PLAY_SESSION token is 984 bytes, I can also mention that the user who opens the DataHub frontpage is automatically provisioned in the database (he/she appears in metadata_aspect_v2;), so the OIDC integration is working up until that point.

This is the code which is complaining btw:

https://github.com/pac4j/pac4j/blob/master/pac4j-core/src/main/java/org/pac4j/core/engine/DefaultCallbackLogic.java

protected void renewSession(final WebContext context, final SessionStore sessionStore, final Config config) {
        final var oldSessionId = sessionStore.getSessionId(context, true).get();
        final var renewed = sessionStore.renewSession(context);
        if (renewed) {
            final var newSessionId = sessionStore.getSessionId(context, true).get();
            LOGGER.debug("Renewing session: {} -> {}", oldSessionId, newSessionId);
            final var clients = config.getClients();
            if (clients != null) {
                final var clientList = clients.getClients();
                for (final var client : clientList) {
                    final var baseClient = (BaseClient) client;
                    baseClient.notifySessionRenewal(oldSessionId, context, sessionStore);
                }
            }
        } else {
            LOGGER.error("Unable to renew the session. The session store may not support this feature");
        }
    }

and the token in the PLAY_SESSION looks like this (which is wrong btw, this is the datahub user not the user logging in):

{
  "actorType": "USER",
  "actorId": "datahub",
  "type": "SESSION",
  "version": "1",
  "exp": 1647690589,
  "jti": "xxxxxxxxxxxxx",
  "sub": "datahub",
  "iss": "datahub-metadata-service"
}

..and I found the problem. The cookie returned after completing the oidc flow is indeed greater than 4096 characters and thus rejected by the browser. I've peeked at the id and auth token returned from cognito and they are pretty slim, same goes for the user-information returned by the userinfo endpoint. The "pac4j_pac4jUserProfiles" part in the PLAY_SESSION is however "gigantic" (3972 chars). Its not base64 encoded, so I can't peek into it.

Does anyone know the encoding on the pac4juserProfiles part, or if there are any others ways of trimming the userprofile than trimming the id/access token?

For others: I had requested 3 claims:

'AUTH_OIDC_SCOPE': 'email openid profile'

I removed the profile claim, this trimmed the PLAY_TOKEN < 4096 chars

I have to reopen this. We have multiple users who are rejected because they have too many claims. We provision groups in datahub based on claims and we have a oauth server which passes along active directory group membership as claims, so we get into this situation quite quickly. Is there any way to further trim the PLAY_TOKEN?

Hi @mariusingjer - We need to understand whether we can slim down the Pac4j profile - perhaps there's a way to limit the profile map to only store specific claims, or to avoid storing the profile in the cookie altogether (I think that's what is happening). After login we do not extract claims from the Pac4j profile so I feel like we can probably clean it up.. I've not had too much time to dig into this yet - have you found anything?

Hi @jjoyce0510 submitted 1 PR to resolve this issue (#5114)

Hi folks,

We've recently submitted a fix to address this which uses a server-side cache for storing the session state. This comes with some caveats - you are not able to scale datahub-frontend beyond a single pod (which is fine for most deployments).

See this PR, which is present in the latest release (v0.8.40): #5114

In the future, some work can still be completed to reduce the attributes which are cached from the OIDC profile, to only those required to make auth work.

Because there is a deployed solution, going to close out the issue.

Thanks
John