Achieving SSO between Custom Login App and SQLPage (OIDC) under same Zitadel Org
I’m looking for guidance on implementing seamless SSO between two applications under the same Zitadel organization, but using different authentication approaches.
Setup
- Both applications are under the same Zitadel host (issuer) and same organization
- They belong to different projects and applications
- The user ID is the same in both applications
- The same user has role and access in both applications
Application 1
- Uses custom login screens
- Authentication is implemented using Zitadel APIs
- Login succeeds and the user is authenticated within the app
Application 2
- Built using SQLPage
- Uses standard OIDC authorization code flow
- On access, it redirects to Zitadel for authentication
Requirement
If a user is already authenticated in Application 1, then when they access Application 2,
they should not be prompted to log in again (SSO).
Questions
1. If authentication in Application 1 is done via APIs (custom login), how can a proper Zitadel browser session be established so that SSO works for Application 2?
2. Is it mandatory that Application 1 also uses a browser-based OIDC /authorize flow (even with a custom UI) to create the Zitadel session?
3. Conceptually, what information does Zitadel store in its session cookies to enable SSO across applications (high-level explanation is enough)?
4. Is it possible (or supported) to manually create or reuse a session/token so that SQLPage can trust it without re-authentication?
5. Are there common pitfalls (ACR, MFA, policies, project separation) that can still force a re-login even under the same organization?
I want to make sure the overall flow is aligned with Zitadel best practices, especially when mixing:
- Custom login implementations
- Standard OIDC clients (like SQLPage)
Any clarification or recommended architecture would be greatly appreciated
Setup
- Both applications are under the same Zitadel host (issuer) and same organization
- They belong to different projects and applications
- The user ID is the same in both applications
- The same user has role and access in both applications
Application 1
- Uses custom login screens
- Authentication is implemented using Zitadel APIs
- Login succeeds and the user is authenticated within the app
Application 2
- Built using SQLPage
- Uses standard OIDC authorization code flow
- On access, it redirects to Zitadel for authentication
Requirement
If a user is already authenticated in Application 1, then when they access Application 2,
they should not be prompted to log in again (SSO).
Questions
1. If authentication in Application 1 is done via APIs (custom login), how can a proper Zitadel browser session be established so that SSO works for Application 2?
2. Is it mandatory that Application 1 also uses a browser-based OIDC /authorize flow (even with a custom UI) to create the Zitadel session?
3. Conceptually, what information does Zitadel store in its session cookies to enable SSO across applications (high-level explanation is enough)?
4. Is it possible (or supported) to manually create or reuse a session/token so that SQLPage can trust it without re-authentication?
5. Are there common pitfalls (ACR, MFA, policies, project separation) that can still force a re-login even under the same organization?
I want to make sure the overall flow is aligned with Zitadel best practices, especially when mixing:
- Custom login implementations
- Standard OIDC clients (like SQLPage)
Any clarification or recommended architecture would be greatly appreciated
