Cross-App SSO is a tenant-wide switch. Turn it on, and a user who signs into one of your applications stays signed in when they navigate to any other application in the same tenant — no second password prompt, no repeated MFA challenge. Turn it off, and every application starts fresh.
Where the toggle lives
Section titled “Where the toggle lives”The SSO toggle sits in the header of the Applications list page, top-right. It is not inside any individual application's settings — it applies to the whole tenant at once.
/screenshots/admin.applications.cross_app_sso/toggle.png Changing the SSO toggle immediately affects every application in this tenant. There is no per-application override. If you need some applications to stand outside the SSO domain, consider giving them their own tenant.
What happens when it is on
Section titled “What happens when it is on”When a user signs into App A, IntelliAuth issues a session for that user. If they then navigate to App B in the same tenant, App B detects the existing session and issues a fresh access token scoped to App B's audience — without prompting for credentials again. From the user's perspective, they clicked a link and they were already in.
The identity is the same identity. The session is the one established at App A. The access token App B receives is freshly minted — it carries App B's audience and the capabilities granted to App B, not a copy of App A's token.
Every cross-app session reuse creates an audit-log entry: who, when, from which application, to which application. Nothing happens silently.
What happens when it is off
Section titled “What happens when it is off”Each application behaves as its own sign-in island. A user who just authenticated in App A will be prompted to sign in again when they open App B, even in the same browser. There are no shared sessions at the tenant level.
When to leave it on
Section titled “When to leave it on”Most multi-product organisations leave Cross-App SSO on. Cymmetri, for example, runs separate applications for their admin console, their customer portal, and their analytics dashboard — all under one tenant. Their users sign in once in the morning and spend the day moving between products without interruption. Turning SSO off would make every product feel like a separate service.
If your tenant has more than one application and they serve the same user base, Cross-App SSO is almost always the right default.
When to turn it off
Section titled “When to turn it off”Turn it off when your applications represent genuinely independent trust boundaries that happen to share a tenant. Examples:
- A high-security workflow — say, a payments interface — where policy requires a fresh credential proof regardless of an existing session.
- Applications subject to PCI DSS, HIPAA, or other regulatory frameworks that mandate per-application authentication.
- A tenant that serves multiple unrelated customer groups and you want clean separation of their sessions.
These situations are uncommon. Most regulatory concerns about session duration are addressed at the token TTL level (in Settings → Tokens) or through per-app MFA policies, not by disabling SSO wholesale.
What Cross-App SSO does not do
Section titled “What Cross-App SSO does not do”It does not share sessions across tenants. Each tenant is its own SSO domain. A user signed in on uat-cymmetri.intelliauth.local gets no session carry-over to prod-cymmetri.intelliauth.local. Tenants are always isolated from each other.
It does not bypass per-application MFA policies. If App B requires a second factor, the user will be prompted for it even if they have a valid session from App A. SSO shares the identity; it does not waive the policies the application has set.
It does not change what is inside a token. The access token App B receives reflects App B's allowed capabilities and TTL settings, not a copy of App A's token.