I have some analysts doing work in GoodData consistently now, and I’ve started getting complaints about getting logged-out and losing any as-yet-unsaved insights that were in progress. I think what’s going on here is needing to set a longer session timeout when the oidc authentication takes place, giving each auth give them a work day’s worth of session before they’d have to worry about a timeout. Looking back here I can’t find anywhere to make such a change, does anyone have the missing bit of info on how to increase the default session lifetime for oidc authenticated users?

Hi Kevin, if you use GD Cloud Native or Cloud with your own OIDC identity provider (IdP), you should be able to set this timeout by setting a proper lifetime for the ID Token directly within this IdP, but only in the case that IdP supports such feature. E.g. Auth0 supports that, see here.

Thanks for that info @Peter Plochan, I’d started to draft a response a WHILE back - but here I come back and I never hit “send”! I’m using Google Workspace as my OIDC provider, and I think based upon https://cloud.google.com/docs/authentication/token-types#id that the ID tokens ALWAYS come out as valid for 1hr. But that they rely on use of the refresh token to get a new ID token. I’m wondering if GoodData isn’t using the refresh token in this manner, resulting in us having every user get logged out after 1hr?

Hi @Kevin Taylor, if you use the Cloud Native product, the refresh token support was released in the version 2.3.0 (see https://support.gooddata.com/hc/en-us/articles/14438190312979-GoodData-CN-2-3-0 and its “Bug Fixes” section). We do not have proper section in the public documentation on that yet, so I will try to describe how it works there. • The CN is doing the “backend” refresh - it uses the stored refresh token during the API call for refreshing the ID token. • The provider must be able to issue the refresh token for

offline_access

scope as stated in the specification or it can just issue the refresh token any time. We do not support exceptions for individual provider types, so it is possible that this

offline_access

scope won’t work in the Google Workspace. • Because the frontend in the CN can call the backend (REST APIs) multiple times in parallel and the backend does the “refresh”, we do not recommend to limit the number of refresh tokens or the number of their usages. This can cause that the session (ID token) won’t be properly refreshed. In the Google Workspace, I have found “There are limits on the number of refresh tokens that are issued: one limit per client/user combination, and another per user across all clients. If your application requests too many refresh tokens, it may run into these limits, in which case older refresh tokens stop working.” statement, so I recommend to set this number to a higher value (e.g. 10 refresh tokens per user/client combination). I hope this will help. If you have any other question, feel free to ask.