SSO prompt=none fails when SPA and Traditional Web App sessions don't share #127
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
When a user logs into the SaaS platform (SPA app) and then clicks "Open Server Dashboard", the server UI attempts
prompt=nonesilent SSO. This succeeds when the Logto session is active for the Traditional Web App, but fails withlogin_requiredwhen the session was established by a different Logto application (the SPA).In practice: if you log in via the SaaS SPA first, then navigate to the server UI,
prompt=nonefails and the login page shows with "Sign in with SSO" button. Clicking SSO shows the Logto sign-in page again. After signing in there, SSO works and the user lands on the server dashboard.If the user was already authenticated via the Traditional Web App (same Logto session),
prompt=nonesucceeds and auto-redirects to the dashboard.Expected
Seamless SSO from SaaS portal to server dashboard without a second sign-in prompt.
Analysis
This may be a Logto behavior where sessions are per-application or per-interaction, not global. The SPA uses PKCE auth code flow, the Traditional Web App uses standard auth code flow. Both are on the same domain and should share the same Logto session cookies.
Possible workarounds:
prompt=noneworksprompt=logininstead ofprompt=noneand let Logto auto-submit if session existsContext
/t/{slug}//t/{slug}/oidc/callbackprompt=nonewhen OIDC is enabledVerified via Playwright: logged in as
acmeadminvia SaaS SPA at/platform/tenant, clicked "Open Server Dashboard" → new tab opened at/t/acme/exchangesfully authenticated without any second sign-in prompt.prompt=nonesilent SSO succeeds correctly — Logto shares the session between the SPA and Traditional Web App as expected.Closing as resolved.