If you are considering switching to SSO (Single Sign-On) and are currently using Ory Kratos for browser logins, here are the key considerations based on the knowledge sources: 1. Supported SSO Methods: Ory Kratos supports SSO via social sign-in providers (like Google, GitHub, Facebook) using OIDC, as well as enterprise SSO with OIDC or SAML for B2B scenarios. You can connect any OpenID Connect-compliant provider or use the onboarding portal for SAML/OIDC enterprise integrations. The onboarding portal is available on select enterprise plans and simplifies connecting external IdPs for your customers or partners [Get started with social sign-in](https://www.ory.sh/docs/kratos/social-signin/overview) [Onboarding portal](https://www.ory.sh/docs/kratos/organizations#onboarding-portal). 2. Browser Login Flows: For browser-based applications, Ory Kratos uses self-service flows secured with cookies and CSRF protection. When enabling SSO, you will typically add an additional login method (e.g.,

oidc

for OIDC providers) in your Kratos configuration. The login UI will then present a "Sign in with SSO" button when appropriate (e.g., based on the user's email domain for B2B SSO) [Login methods](https://www.ory.sh/docs/kratos/self-service/flows/user-login) [See it live](https://www.ory.sh/docs/kratos/organizations#see-it-live). 3. Configuration: You can configure SSO providers through the Ory Console or CLI. For OIDC, you need to provide the client ID, client secret, and issuer URL. For SAML, the onboarding portal can be used for easier setup. You can also customize OAuth scopes and data mapping to control what user data is imported [Connecting a project to the SSO provider](https://www.ory.sh/docs/kratos/social-signin/ory#connecting-a-project-to-the-sso-provider). 4. UI and User Experience: The login flow for browser clients relies on HTTP redirects between Ory, your login UI, and the user's browser. You can use Ory's default UI or bring your own custom UI. The UI should be hosted on the same top-level domain as Ory to avoid issues with cookies [Initialize login flow](https://www.ory.sh/docs/kratos/self-service/flows/user-login#initialize-login-flow) [Custom UI integration](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration). 5. Security Considerations: - Ensure your application and Ory are on the same top-level domain for cookie/session management. - Use browser flows (not API flows) for browser-based apps to avoid CSRF and other security issues. - Ory manages session cookies and CSRF tokens for browser security [Local development](https://www.ory.sh/docs/getting-started/local-development#local-development) [Self-service flows](https://www.ory.sh/docs/kratos/self-service#performing-login-registration-settings--flows). 6. B2B/Enterprise SSO: If you need to support organizational logins (B2B), Ory Kratos offers features to group users by organization and enable SSO per organization, including self-service onboarding for IT admins [Onboarding portal](https://www.ory.sh/docs/kratos/organizations#onboarding-portal). Summary: Switching to SSO with Ory Kratos for browser logins is well-supported, but you should plan for provider configuration, UI integration, domain/cookie management, and security best practices. For enterprise/B2B use cases, consider leveraging the onboarding portal for streamlined IdP integration. If you have specific requirements (e.g., SAML vs. OIDC, multi-tenancy, custom UI), these may influence your setup and plan selection. If you need more details on a particular SSO scenario, please specify!

The main difference between SSO via social sign-in and SSO B2B in Ory is the intended use case and the type of identity provider being integrated: --- SSO via Social Sign-In: - Purpose: Allows end-users to log in using their personal accounts from popular public identity providers such as Google, GitHub, Facebook, or Microsoft. - Typical Use Case: Business-to-Consumer (B2C) applications where users want a quick and familiar way to sign up or log in without creating a new account. - Configuration: You add social providers in the Ory Console or via configuration, typically requiring a client ID and secret from the provider. Ory offers pre-configured connectors for many popular providers, and you can also add any generic OIDC-compliant provider [Get started with social sign-in](https://www.ory.sh/docs/kratos/social-signin/overview) [Social sign-in guide](https://www.ory.sh/docs/identities/get-started/social-sign-in). - User Experience: Users see buttons like "Sign in with Google" on your login page. After authenticating with the provider, a new account is created or an existing one is linked. --- SSO B2B (Enterprise SSO): - Purpose: Enables users from partner organizations or enterprise clients to log in using their corporate identity provider, such as Microsoft Entra ID (Azure AD), Okta, or Google Workspace. - Typical Use Case: Business-to-Business (B2B) or enterprise SaaS applications where each customer organization wants to use their own IdP for employee access. - Configuration: Uses OIDC or SAML protocols. Organizations are created in Ory, and each can have one or more SSO connections (OIDC or SAML). The onboarding portal can be used to simplify setup for enterprise clients [B2B Single Sign-On & SAML](https://www.ory.sh/docs/kratos/organizations) [Onboarding portal](https://www.ory.sh/docs/kratos/organizations#onboarding-portal). - User Experience: Users are typically directed to their organization's login page (based on email domain or organization selection). After authenticating with their corporate IdP, they gain access to your application as a member of their organization. --- Summary Table: | Feature | Social Sign-In SSO | B2B/Enterprise SSO | |------------------------|-----------------------------------|-----------------------------------| | Target Users | Individual consumers | Employees of partner organizations| | IdP Type | Public (Google, GitHub, etc.) | Enterprise (Okta, Azure AD, etc.) | | Protocols | OIDC (OpenID Connect) | OIDC and SAML | | Use Case | B2C | B2B, Enterprise SaaS | | Organization Support | No | Yes (organizations, domains) | | Onboarding Portal | No | Yes | --- In short: - Social sign-in SSO is for letting users log in with their personal accounts from public providers. - B2B SSO is for letting users from specific organizations log in with their company credentials, supporting enterprise IdPs and organizational management [B2B Single Sign-On & SAML](https://www.ory.sh/docs/kratos/organizations) [Social sign-in overview](https://www.ory.sh/docs/kratos/social-signin/overview).

To use the same credentials across different domains, Ory recommends two main approaches: 1. Multiple Custom Domains with Ory Network (Multibrand Feature): You can add multiple custom domains to your Ory Network project using the Multibrand feature. This allows users to have a single account that works across all your domains. However, due to browser security restrictions, session cookies are isolated per domain. This means users will need to authenticate separately on each domain, but they can use the same credentials (username/password or SSO) everywhere. Each domain will have its own session, but the identity is shared across domains within the same Ory project [Multiple custom domains](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui#multiple-custom-domains). 2. OpenID Connect (OIDC) for Cross-Domain SSO: As an alternative, you can use Ory as an OIDC provider. Each of your applications (on different domains) acts as an OIDC client and delegates authentication to a central Ory project. This way, users authenticate once with the central identity provider and can use the same credentials across all domains. However, even with OIDC, each domain will have its own session due to cookie isolation, but the authentication is centralized [Multiple custom domains](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui#multiple-custom-domains). Important Note: While users can use the same credentials across domains, browser security means they will have to log in separately on each domain (one session per domain). There is no way to share browser session cookies across different top-level domains for security reasons. Summary: - Use the Multibrand feature to manage multiple domains with shared credentials. - Use OIDC to centralize authentication. - Users will have to log in on each domain, but can use the same credentials everywhere. For more details, see the documentation on [Multiple custom domains](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui#multiple-custom-domains).

Certainly! Here are the pros and cons of the two main approaches for using the same credentials across different domains with Ory, based strictly on the provided knowledge sources: --- ### 1. Multiple Custom Domains with Ory Network (Multibrand Feature) Pros: - Single Account Across Domains: Users can use the same credentials (managed by a single Ory project) to log in to all your domains, supporting a unified identity experience [Multiple custom domains](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui#multiple-custom-domains). - Custom UI per Domain: You can serve different UI views for each domain, allowing for brand-specific user experiences while maintaining a shared identity backend. - Centralized Identity Management: All user accounts are managed centrally, simplifying administration. Cons: - Session Isolation: Due to browser security, session cookies are isolated per domain. Users must authenticate separately on each domain, resulting in one session per domain [Multiple custom domains](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui#multiple-custom-domains). - No True Cross-Domain SSO: Users cannot be automatically signed in across domains; they need to log in on each one. --- ### 2. OpenID Connect (OIDC) for Cross-Domain SSO Pros: - Centralized Authentication: All domains delegate authentication to a central Ory project, ensuring consistent credential usage and authentication logic [Multiple custom domains](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui#multiple-custom-domains). - Flexible Integration: Each application (on a different domain) can act as an OIDC client, making it easier to add or remove domains/applications as needed. - Standard Protocol: OIDC is a widely adopted standard, making integration with other systems and providers straightforward. Cons: - Session Isolation Remains: Even with OIDC, browser session cookies are still isolated per domain, so users will have to log in on each domain (one session per domain) [Multiple custom domains](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui#multiple-custom-domains). - Additional Complexity: Setting up OIDC clients and flows adds some configuration and operational overhead compared to a single project with multiple domains. --- Summary Table: | Approach | Pros | Cons | |----------------------------------|----------------------------------------------------------------------|---------------------------------------------------------------------------------------| | Multiple Custom Domains | Unified credentials, custom UI per domain, centralized management | Session isolation (login per domain), no true cross-domain SSO | | OIDC for Cross-Domain SSO | Centralized authentication, flexible, standard protocol | Session isolation (login per domain), additional setup complexity | --- > Both approaches allow users to use the same credentials across domains, but due to browser security, users will have to log in separately on each domain. There is no way to share browser session cookies across different top-level domains [Multiple custom domains](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui#multiple-custom-domains).