Skip to main content
Identity Authority
Category: Federation & SSO

Cross-Domain SSO

Also known as: CDSSO, Cross-Domain Single Sign-On, Cross-Domain Authentication
Simply put

Cross-Domain SSO lets a person sign in once and then reach several separate websites or applications that live on different internet domains without having to log in again at each one. It solves the problem that a login session established on one domain normally cannot be recognized by a different domain. The exact mechanism and user experience depend on the vendor and how the deployment is configured.

Formal definition

Cross-Domain SSO (CDSSO) is a single sign-on approach that extends an authenticated session across services hosted on distinct DNS domains, allowing a principal to access multiple independent applications from one login. It addresses a core browser constraint: session cookies are scoped to a domain and, in most deployments, are not transmitted across different registrable domains, so a session established at one domain is not automatically presented to another. Implementations typically bridge domains using federation or token-passing techniques rather than shared cookies; the specific standards, profiles, and session-propagation methods vary by vendor and configuration and are out of scope for this general definition. Note that CDSSO governs authentication and session continuity across domains; it does not by itself determine what resources a principal is authorized to access at each service, which remains a separate authorization concern.

Why it matters

Modern organizations rarely operate all of their applications under a single internet domain. A company may run a customer portal, a support site, an internal tool, and a partner-facing service across several distinct DNS domains, yet users expect to authenticate once and move between them without repeated logins. The technical obstacle is fundamental to how browsers work: session cookies are scoped to a domain and, in most deployments, are not transmitted across different registrable domains. As documented in real deployment discussions, a session cookie established for one domain simply does not get sent for another, and SSO does not automatically cross that boundary. Cross-Domain SSO exists to bridge exactly this gap so that authentication and session continuity extend across otherwise independent applications.

Without a deliberate CDSSO approach, each domain effectively becomes its own authentication island, forcing users to re-enter credentials and multiplying the number of login prompts, help-desk password resets, and abandoned sessions. For organizations consolidating multiple products or acquisitions under different domains, this friction directly affects usability and adoption. Vendors such as Ping Identity describe CDSSO as a capability that lets users access multiple independent services from a single login session, and ICE Mortgage Technology's account-linking service uses a cross-domain SSO approach to provide seamless access across several enterprise applications.

It is important to keep scope precise: CDSSO addresses authentication and session propagation across domains, not what a principal is permitted to do once authenticated. Authorization decisions at each individual service remain a separate concern that CDSSO does not resolve. Treating cross-domain login continuity as if it also settled per-application access rights is a common conceptual error that can leave authorization gaps unaddressed.

Who it's relevant to

Security Architects
Architects designing systems that span multiple DNS domains must decide how to extend authenticated sessions across those boundaries given that domain-scoped cookies will not travel between registrable domains. They evaluate whether federation or token-passing approaches fit the deployment, and they must keep the cross-domain authentication design distinct from the authorization model applied at each individual service.
IAM Engineers
Engineers implementing and troubleshooting SSO frequently encounter the concrete symptom that a session cookie for one domain is not sent for another, breaking single sign-on across sites. Understanding CDSSO helps them select and configure the vendor-specific session-propagation mechanism appropriate to their environment, whether coordinating multiple custom login domains against a shared identity provider or integrating a dedicated cross-domain authentication service.
System Administrators
Administrators operating multiple applications hosted on different domains are often responsible for the day-to-day login experience and the help-desk burden that results from repeated prompts. They benefit from understanding why cross-domain login continuity requires deliberate configuration and how the chosen deployment's behavior may differ from single-domain SSO.
Compliance and Identity Governance Leads
Governance and compliance stakeholders need to recognize that CDSSO addresses authentication and session continuity, not authorization. Seamless cross-domain login does not by itself establish what a principal may access at each service, so per-application access rights, reviews, and certifications must still be governed separately from the cross-domain sign-on mechanism.

Inside CDSSO

Identity Provider (IdP)
The authoritative party that authenticates a principal in one domain and asserts the resulting authentication (and often attribute) information to relying parties across trust boundaries. In cross-domain SSO the IdP is typically the anchor of the trust relationship.
Service Provider / Relying Party (SP/RP)
The application or domain that consumes an assertion or token to establish an authenticated session without re-prompting the user. In SAML 2.0 this party is termed the Service Provider; in OpenID Connect (OIDC Core) it is the Relying Party.
Federation Trust
The pre-established trust configuration between domains, typically expressed through exchanged metadata, signing certificates, and endpoint URLs. This trust governs which IdP assertions an SP will accept and is a prerequisite for cross-domain SSO.
Assertion or Token
The signed artifact conveying authentication results across domains, such as a SAML 2.0 assertion or an OIDC ID token. Note that being signed establishes integrity and origin but does not, by itself, mean the artifact is encrypted or confidential.
Session Context and Single Logout
Mechanisms for correlating sessions across domains, including SAML 2.0 Single Logout (SLO) or OIDC session management profiles. Cross-domain logout behavior varies significantly by protocol profile and deployment configuration.
Protocol Binding
The transport mechanism used to move messages between domains, such as SAML 2.0 HTTP-Redirect or HTTP-POST bindings, or OIDC redirect flows over front-channel and back-channel. The chosen binding affects how assertions or tokens traverse the browser and network.

Common questions

Answers to the questions practitioners most commonly ask about CDSSO.

Does cross-domain SSO mean my session cookie is shared across all the domains involved?
No. Because browser cookies are scoped to a single origin (or a defined cookie domain), a session established at one domain is not directly readable by another domain. Cross-domain SSO typically works by having each service provider or relying party rely on assertions or tokens issued by a common identity provider, rather than by sharing a single cookie across unrelated domains. Each domain generally establishes its own local session after validating the federated assertion or token.
Is cross-domain SSO the same thing as authorizing a user's access to resources in each domain?
No, and conflating the two is a common error. Cross-domain SSO addresses authentication, establishing and conveying that a user was verified by a trusted identity provider so they need not re-authenticate at each domain. It does not determine what the authenticated user may do in a given domain. Authorization decisions are made separately by each relying party, often using claims or attributes from the assertion together with its own access control model (for example RBAC or ABAC). Identification, authentication, and authorization remain distinct steps.
Which protocols are typically used to implement cross-domain SSO?
In most web-based deployments, cross-domain SSO is implemented with SAML 2.0 (an XML-based federation standard for web SSO) or with OpenID Connect (the authentication layer built on OAuth 2.0). The choice depends on factors such as existing relying party support, whether you need XML-based assertions or JSON/JWT-based ID tokens, and vendor tooling. OAuth 2.0 alone is a delegated authorization framework and is not sufficient on its own for authenticating the user in an SSO flow.
How are sessions and single logout handled across the participating domains?
Each domain typically maintains its own local session after consuming the federated assertion or token, so session lifetimes can differ per relying party depending on configuration. Coordinated logout is not automatic: it generally requires an explicit single logout mechanism, such as SAML 2.0 Single Logout or an OIDC logout profile, and support varies by vendor and profile. In many deployments single logout is only partially reliable, so ending a session at the identity provider may not immediately terminate every downstream session unless the relevant logout profile is implemented on all sides.
What trust configuration is needed between the identity provider and each domain?
Each relying party or service provider must establish a trust relationship with the identity provider, which typically involves exchanging metadata, signing keys or certificates, and agreed endpoints. In SAML 2.0 this is usually done through metadata exchange and configured signing/encryption certificates; in OpenID Connect it is typically done through client registration and published discovery/JWKS endpoints. Note that a signed assertion or token establishes integrity and origin but is not the same as encryption, so protecting assertions in transit and deciding whether to encrypt them are separate configuration decisions.
How does provisioning relate to cross-domain SSO once a user can authenticate across domains?
Cross-domain SSO handles runtime authentication, but it does not by itself create or manage the user accounts and entitlements in each domain. Those are identity governance and administration concerns, typically addressed through provisioning, often via SCIM or vendor-specific connectors, so that an account and its attributes exist in a relying party before or at the time of first access. Depending on configuration, some deployments use just-in-time provisioning driven by assertion attributes, while others provision accounts in advance; either way, access reviews, certification, and segregation of duties remain governance functions separate from the SSO flow.

Common misconceptions

Cross-domain SSO means the user is authorized to do the same things in every domain.
SSO addresses authentication continuity across domains, not authorization. Each relying party still makes its own authorization decisions based on its access control model (for example RBAC or ABAC) and the attributes it receives or resolves; a shared authenticated session does not imply shared entitlements.
OAuth 2.0 by itself provides cross-domain single sign-on for users.
OAuth 2.0 is a delegated authorization framework and is not an authentication protocol. Cross-domain user SSO is typically built on an authentication layer such as OpenID Connect (which sits on top of OAuth 2.0) or on SAML 2.0. Using OAuth 2.0 access tokens as evidence of user authentication is a common but incorrect pattern.
Because SSO assertions are signed, the identity data crossing domains is protected from disclosure.
A signature provides integrity and proof of origin, not confidentiality. Unless the assertion or token is also encrypted (for example SAML encrypted assertions or JWE), attribute contents may be readable in transit or at intermediaries depending on the binding and configuration.

Best practices

Establish and periodically rotate federation trust material, including signing certificates and metadata, and validate that each relying party accepts only assertions or tokens from expected issuers and audiences.
Keep authentication and authorization concerns separate: use the cross-domain SSO flow to convey verified identity, and let each domain enforce its own authorization decisions through its access control model rather than assuming uniform entitlements.
Choose the correct protocol for the goal, using OpenID Connect (OIDC Core) or SAML 2.0 for user authentication and reserving OAuth 2.0 for delegated authorization, and document the specific version and profile in use.
Encrypt assertions or tokens that carry sensitive attributes rather than relying on signatures alone, since signing does not provide confidentiality across domains.
Validate all security-relevant claims at the relying party, including issuer, audience, expiration, and signature, and confirm behavior against the specific binding and profile in your deployment rather than assuming defaults.
Design and test cross-domain logout explicitly, since Single Logout and session termination behavior varies by protocol profile and vendor and may not propagate reliably without deliberate configuration.
Promotional banner for the Pentest Readiness checklist download