I run a Morse Code website that allows users to translate text into Morse code, decode messages, and save their learning progress. Recently, I integrated Okta authentication so users can securely access their saved translations and personalized settings. The implementation generally works as expected, and users can sign in successfully without issues. However, I am encountering a problem where authenticated sessions appear to expire unexpectedly during normal use. This issue is affecting users who spend extended periods interacting with the application.
The website is highly interactive and most activity occurs directly in the browser after login. Users often spend a long time practicing Morse code, listening to audio playback, and working through translation exercises. During these sessions, they may not perform actions that generate requests to protected backend endpoints. After remaining active in the application for some time, users suddenly encounter authentication errors when attempting to save progress or access account-related features.
What makes the issue difficult to diagnose is that the user is actively using the website when the session expires. From the user’s perspective, the application appears fully active because they continue interacting with the translator interface. However, when an authenticated request is finally made, the access token is no longer valid and the operation fails. This creates confusion because users believe they are still signed in based on the visible state of the application.
I have reviewed token expiration settings and implemented the recommended authentication flow for a single-page application. The application attempts silent token renewal where possible, but there are situations where renewal does not appear to occur before the token expires. As a result, users occasionally lose the ability to access protected features until they manually sign in again. I am trying to determine whether my implementation is missing a recommended session management pattern.
The challenge is balancing security with usability. I understand the importance of token expiration and proper session controls, but I also want users to have a seamless experience while spending long periods learning Morse code. Because the application is educational and highly interactive, users may remain on a single page for extended durations without performing actions that trigger authentication-related requests. I would like to maintain secure authentication without interrupting legitimate usage.
Has anyone implemented Okta authentication for a similar single-page application with long-running user sessions? I would appreciate guidance on recommended approaches for session management, token renewal, and maintaining authentication during extended client-side activity. If there are best practices for ensuring users remain authenticated while actively using the application, I would be grateful for any advice or implementation recommendations. Sorry for long post!
I think the issue over here is why the Refresh token/silentRenewal is failing to get a valid access token for the user. Since the refresh token renews the tokens, the app won’t have to ask for login.
The application attempts silent token renewal where possible, but there are situations where renewal does not appear to occur before the token expires - I think it’s worth getting down to what the situations are in which this is failing. Since, if you are using Okta SDKs, ideally, it shouldn’t fail.
Before I start changing other session settings, I’ll focus on understanding why the silent renewal or refresh token flow is failing in those specific situations. I’m using the Okta SDK, so I agree that the renewal process should normally be seamless, which suggests there may be something in my implementation or runtime conditions that I’m overlooking.
I’ll add more detailed logging around the token lifecycle to capture exactly when renewal attempts occur, whether they’re triggered before expiration, and any errors returned by the SDK. Hopefully that will help narrow down whether the issue is related to browser conditions, application state, or the renewal flow itself. Thanks for pointing me in that direction.
Hi @joeroot
I would suggest reviewing the implementation of libraries once and to see if your code is using two libraries. There could be 401s, even if the token was renewed successfully, and it can be because of two libraries being used and not in sync.
Particularly, check if you are using @okta/okta-auth-js and @okta/okta-react.
What can happen is the first library is able to renew the tokens properly and the second library is making use of those tokens in your code which are expired because it did not fetch the latest token which is renewed.
Another part would be to look at the third-party cookies being disabled on the browser - that may fail the OKTA API over-the-network calls (/authorize may not identify the OKTA session in the browser in this scenario!) and result in failure - rerouting back to login page. *
*
*However, this is only true if you are not using refresh token based renewal and OKTA domain is different than your application domain.