Skip to main content

Hello, is it possible to set the Session expiration for an OpenID provider, or stay logged in for longer than 30 minutes when using external OpenID provider. See above the screenshot of SF 2025.2, in which it is possible to set the expiration for the external provider.

 

We are in the process of assessing our chances to upgrade to this new SF version. But for now we wish to have the `Stay signed in` option like logging in with the local account.

Hi Stijn,

We’re not able to influence the pages or behavior of the external OpenID provider, such as adding a “stay logged in” option.

In your screenshot, you already highlighted the relevant field that determines the session timeout for external login. When using local login, enabling “stay logged in” extends the session duration to 14 days. You could consider increasing the session expiration on the OpenID provider in IAM for all users—for example, to X hours or even X days—if that better fits your use case.

However, please be aware that extending session durations can introduce security risks, especially on shared devices.

Would this be a viable solution in your situation?


Hello ​@Erik Brink,

Thank you for your response.

Currently we are not in the position to change the settings for the OpenID provider in IAM for all users, since we are not yet on that version that includes this feature.

However, there must perhaps be some sort of intermediate solution, since the session expiration had changed in 2024.1.14 version when compared to 2024.1.10. And then later this change was introduced that it can be configured.


No we can not offer this for older platform version, since it required a new field in IAM.

This is a good argument to speed up the upgrade to 2025.1 or 2025.2 :)


Indicium 2024.1.10 does not feature this behavior of ending the session upon 30 minutes of inactivity.

However, in another environment of ours with Indicium 2024.1.13, this happens to be the case.

Nowhere in the release notes of the product updates it can be found, which version introduces this fix to adhere to the originally intended behavior. Could you please clarify which version introduced this fix?

This is crucial to the temporary solution of our environment.


Here you will find an explanation from Vincent 


@PatrickW ​@Vincent Doppenberg 

Thankyou for your response late at night.

Indicium 2024.1.10 released on January 15, 2024
This version does not expire the session after 30 minutes without checking the checkbox.

The post you referred to is from January 30, 2024
The current version at that date is 2024.1.10.

Indicium 2024.1.11 released on February 12, 2024
This is after the post. Here I wonder whether or not that version introduced the ‘fix’ to the session expiration.

 

From the mentioned post and other posts I can’t decipher which specific version made the change that ​@Vincent Doppenberg is referring to?


https://community.thinkwisesoftware.com/questions%2Dconversations%2D78/session%2Dis%2Dexpired%2Din%2Duniversal%2Dgui%2D4743?postid=18389#post18389#post18389

 


Hello ​@Stijn Schuurman,

Indicium 2024.1.10 released on January 15, 2024
This version does not expire the session after 30 minutes without checking the checkbox.

Despite this, I do believe it was version 2024.1.10.0 which introduced the change that not checking ‘Remember me’ or ‘Stay signed in’ caused the session to expire after 30 minutes of inactivity.

Inactivity being a keyword here. Is it possible that in your test case there was a badge, change detection, auto refresh or some other periodic request going to Indicium which kept the session alive? Because the 30 minutes is a sliding expiration window, meaning that if Indicium receives a request with a cookie that is halfway through its lifetime, it will extend the expiration time.

It looks like version 2023.3.13.2 was the last version in which the session did not expire after 30 minutes. And as you know, as of platform version 2024.3, we have started supporting configuring explicit session expiration times for users and OpenID providers.

I hope this helps.

 


@Stijn Schuurman long story short: a Thinkwise fix is only available in combination with Platform version 2024.3. As you can see in the topic that ​@PatrickW referred to, you are not the first customer who experienced this issue. In that topic I also suggest a temporary workaround if upgrading to 2024.3 or higher isn’t a short-term option.

I am curious though, what’s holding you back from upgrading to one of the latest Platform versions?


@Arie V 

The topic in which you suggest a workaround, is from a colleague of mine.

Upgrading to one of the latest platform is on our timeline, however, we are hesitant to upgrade since it introduces new unknown errors. See my recent post about the new Indicium version for example: 

 


@Arie V 

Additionally, the newer platform versions end support for the WebGUI.

Currently, a subset of our clients are not converted to the UniversalGUI due to a poor performance of common use-cases. Refer to the following post to which you also replied: 

I have received an update from Thinkwise with the release of the new UGUI that does not perform a commit upon just passing by a record while not changing it.
Despite this improvement, and also specifying in the performance settings of this subject to not do layout() procedures, also no default() procedures, the Universal GUI is still significantly slower than the WebGUI counterpart. Additionally, the UniversalGUI is not just slower, it is also disregarding user-inputs. When submitting down-key arrow 5 times, even after waiting it only processes 3 inputs.

 

I just created a new ticket for this urgent persisting problem.