K
Kinde•2mo ago
Martin

Recommended approach for handling long lived tabs

My understanding is that when a user logs in with Kinde they are issued a short lived access token and a medium lifetime refresh token. Once the refresh token has expired, the user is effectively no longer logged in. Whats is the recommended approach for handling long lived tabs? If a user opens a tab to my Kinde authenticated website, logs in, then walks away from their laptop for a week, and comes back to the tab - what should happen next? One option would be to automatically / with a prompt redirect them to login again. However, if they have any clientside unsaved changes then this risks losing those changes. Is there any way to support logging the user back in without them having to be redirected back to Kinde?
3 Replies
Koosha-Kinde
Koosha-Kinde•2mo ago
Hi Martin, Thanks for reaching out.

You’re right, Kinde issues a short-lived access token and a longer-lived refresh token (issued when you request the offline scope). The SDK quietly refreshes access tokens until the refresh token expires. For long-lived tabs, the recommended approach is: 1. Let the SDK keep the session alive as long as possible - Make sure your app requests the offline scope so a refresh token is issued. - Use a custom domain so Kinde can store the refresh token in a secure, httpOnly, first-party cookie on your domain (more reliable across reloads/tabs). 2. When the user returns after a long time, try silent sign-in first - Start an auth request with prompt=none. If the user still has a valid Kinde SSO session, they’ll be signed back in without seeing a login screen and without losing the page. If not, Kinde will return login_required, and you can then show a “Session expired” message. 3. Prevent data loss if a real login is needed - Before redirecting to sign in, save any unsaved work to localStorage/IndexedDB and restore it after the user returns. (This is an app-side UX pattern.) 4. Tune session behavior to fit your needs - In Kinde, check Settings → Environment → Applications → Sessions. Choose persistent vs non-persistent SSO cookies and adjust session lifetimes to match your “left a tab open for a week” scenario. (You can also configure this per organization if needed.) Let me know if this helps, Thanks
Hillary
Hillary•5w ago
This is helpful for me as well, thanks. My scenario is this have two apps, one has the normal Kinde login in the /api/login page, and then another app which reuses the session from the first app. This second app is embedded in the first app. - So on the second app I use slient login with prompt=none and offiline scope, and my middleware would look like this: 
      const loginUrl = await kinde?.login({
        authUrlParams: {
          prompt: 'none',
          scope: 'offline'
        }
      })
      const loginUrl = await kinde?.login({
        authUrlParams: {
          prompt: 'none',
          scope: 'offline'
        }
      })
The problem in my case is that I keep getting the login_required after some despite the first app being logged in and working well How best can I deal with this to ensure that the second app only requests or redirects to the first apps login page when only one logs out from the first app
Koosha-Kinde
Koosha-Kinde•4w ago
Hi Hillary, thanks for the details! login_required in the embedded app (App B) usually means it can’t see a valid Kinde session cookie from the main app (App A), especially in an iframe. Fix in 4 steps: 1. Use a Kinde custom domain (e.g. auth.yourdomain.com) and point both apps to it.
→ This makes the refresh/session cookies first-party, so silent login in the iframe is reliable. 2. Keep scopes/org the same in both apps (include offline, same audience/org).
→ Scope or org mismatches can cause silent auth to fail. 3. Parent handles interactive login; iframe stays silent. - App B tries prompt=none on load. - If it gets login_required, don’t redirect inside the iframe. - Post a message to App A to do a top-level login; after success, App B retries prompt=none. 4. Prevent data loss:
Save any unsaved form data to localStorage/IndexedDB before any redirect, restore after login. Let me know if this helps, Thanks

Did you find this page helpful?