SSO prompt=none fails when SPA and Traditional Web App sessions don't share #127

Closed
opened 2026-04-10 09:56:24 +02:00 by claude · 1 comment
Owner

Problem

When a user logs into the SaaS platform (SPA app) and then clicks "Open Server Dashboard", the server UI attempts prompt=none silent SSO. This succeeds when the Logto session is active for the Traditional Web App, but fails with login_required when 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=none fails 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=none succeeds 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:

  • A) Accept the behavior — user clicks "Sign in with SSO" once, after that prompt=none works
  • B) Use prompt=login instead of prompt=none and let Logto auto-submit if session exists
  • C) Investigate Logto session sharing between SPA and Traditional Web App

Context

  • SaaS provisions per-tenant servers at /t/{slug}/
  • OIDC config is auto-pushed to servers during provisioning
  • Redirect URIs are registered for /t/{slug}/oidc/callback
  • The server login page auto-redirects with prompt=none when OIDC is enabled
## Problem When a user logs into the SaaS platform (SPA app) and then clicks "Open Server Dashboard", the server UI attempts `prompt=none` silent SSO. This succeeds when the Logto session is active for the Traditional Web App, but fails with `login_required` when 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=none` fails 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=none` succeeds 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: - A) Accept the behavior — user clicks "Sign in with SSO" once, after that `prompt=none` works - B) Use `prompt=login` instead of `prompt=none` and let Logto auto-submit if session exists - C) Investigate Logto session sharing between SPA and Traditional Web App ## Context - SaaS provisions per-tenant servers at `/t/{slug}/` - OIDC config is auto-pushed to servers during provisioning - Redirect URIs are registered for `/t/{slug}/oidc/callback` - The server login page auto-redirects with `prompt=none` when OIDC is enabled
Author
Owner

Verified via Playwright: logged in as acmeadmin via SaaS SPA at /platform/tenant, clicked "Open Server Dashboard" → new tab opened at /t/acme/exchanges fully authenticated without any second sign-in prompt. prompt=none silent SSO succeeds correctly — Logto shares the session between the SPA and Traditional Web App as expected.

Closing as resolved.

Verified via Playwright: logged in as `acmeadmin` via SaaS SPA at `/platform/tenant`, clicked "Open Server Dashboard" → new tab opened at `/t/acme/exchanges` fully authenticated without any second sign-in prompt. `prompt=none` silent SSO succeeds correctly — Logto shares the session between the SPA and Traditional Web App as expected. Closing as resolved.
Sign in to join this conversation.