Achieving SSO between Custom Login App and SQLPage (OIDC) under same Zitadel Org
❌Unsolved❓Question
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
