I'm investigating unattended authentication renewal in a desktop application using the self-hosted Repository API, not Laserfiche Cloud.
Environment
- API Server version: 2.0.2608.10
- Authentication: LFDS authorization-code flow with PKCE
- AccessTokenExpirationLimit: 00:15
- SessionIdleTimeout: 00:15
- Repository polling: every 60 seconds
Observed behavior
Initial authentication returns an access token with a 15-minute lifetime and a refresh token expiring approximately 30 minutes after sign-in.
Refreshing succeeds and returns new access and refresh tokens. Our application persists the replacement refresh token and uses it for the next request. However, each replacement refresh token retains the original expiration timestamp, rather than extending it.
For example, using VM-local times:
- 8:08:17 PM: Initial sign-in; refresh token expires at 8:38:17 PM.
- 8:34:47 PM: Refresh succeeds, but replacement refresh-token expiration remains 8:38:17 PM.
- 8:36:17 PM: Another refresh succeeds, with the same expiration.
- Repository API requests continue succeeding through 8:49:12 PM.
- 8:49:47 PM: Refresh fails with HTTP 400.
The API server trace reports SecurityTokenExpiredException and:
IDX10223: Lifetime validation failed. The token is expired.
ValidTo (UTC): 10/15/2026 3:38:17 AM
Current time (UTC): 10/15/2026 3:49:47 AM
Questions
- In this self-hosted API version, should refresh-token rotation extend the expiration, or is the original deadline an absolute lifetime requiring a new authorization-code flow?
- Could refreshing proactively, before access-token expiration, cause this behavior because the underlying session is reused?
- Is there a supported configuration or recommended approach for maintaining an actively used session without repeated user interaction?
- The self-hosted installation guide documents SessionIdleTimeout, while the authentication page’s Session Management section says IdleSessionTimeout. Which setting applies to this version?