Short answer: A direct “Kratos social sign-in → Polis” OIDC hookup is not supported out of the box because Polis needs tenant/product context during authorization, and Kratos’s generic OIDC provider doesn’t expose a way to add those custom query parameters. Details: - Polis determines which SSO connection to use from tenant/product. You can pass them either by encoding them into client_id (special “dummy + tenant/product” pattern) or by adding tenant/product as custom params in the authorize request. [[Authorize](https://www.ory.sh/docs/polis/sso-flow#authorize)] - Polis’s OAuth flow is standards-based, but it’s intentionally multi-tenant and expects that routing context. [[Single Sign-On](https://www.ory.sh/docs/polis/sso-flow); [Example flow](https://www.ory.sh/docs/polis/sso-flow/example-flow)] - Kratos can add a generic OIDC provider (“social sign-in”), but the docs show standard fields only (issuer URL, client ID/secret, scopes, mappings) and do not document a way to inject arbitrary custom query parameters into the upstream authorize request. [[Generic provider](https://www.ory.sh/docs/kratos/social-signin/generic); [Connecting a project](https://www.ory.sh/docs/kratos/social-signin/ory#connecting-a-project-to-the-sso-provider)] Because of that mismatch, there isn’t a documented, direct Kratos→Polis OIDC integration path that lets you supply tenant/product at authorize time. The recommended Polis patterns route via your app, which initiates the Polis flow (including tenant/product), handles the code exchange, and then proceeds with your app’s session logic. [[Single Sign-On Authentication](https://www.ory.sh/docs/polis/guides/npm-library#single-sign-on-authentication); [Code exchange](https://www.ory.sh/docs/polis/sso-flow#code-exchange)] Given Kratos’s role, a pragmatic approach is: - Have your application initiate the Polis authorization (with tenant/product), perform the code exchange against Polis, obtain the user profile/token from Polis, and then create or link the user/session in Kratos via your backend logic. This aligns with Polis’s documented flows and preserves the tenant routing. [[Single Sign-On Authentication](https://www.ory.sh/docs/polis/guides/npm-library#single-sign-on-authentication); [Authorize](https://www.ory.sh/docs/polis/sso-flow#authorize)] Limitations: - The knowledge sources don’t document a way in Kratos to append custom authorize parameters for upstream OIDC providers, nor an official Kratos→Polis recipe. If you must keep Kratos as the primary IdP, you would need an intermediary that carries tenant/product into the Polis call and then reconciles identities/sessions on the Kratos side. [[Generic provider](https://www.ory.sh/docs/kratos/social-signin/generic); [Authorize](https://www.ory.sh/docs/polis/sso-flow#authorize)] If helpful, I can sketch the exact request sequence your backend would perform (authorize → handle Polis callback → token exchange → userinfo → create session in Kratos) based on the cited flows.