¿Qué es el SSO?

SSO is an authentication method that allows a user to sign in one time with a single set of credentials and gain access to all the applications and services they are authorized to use. Instead of maintaining a different password for every application, the user authenticates once with an identity provider, and that authentication is trusted by each connected service.

In a business environment, SSO is typically managed by an internal IT or security team and connected to the organization’s identity provider. It is closely related to broader identity and access management, and it often serves as the entry point for layering additional controls like multi-factor authentication, adaptive policies, and passwordless authentication.

For a deeper look at why SSO has become a workforce essential, see Single Sign-On: You Need It Now More Than Ever.

SSO works by connecting the identity provider, which handles authentication, and the service provider, which is the application or system the user is trying to access. When a user attempts to sign in, the service provider hands off the authentication request to the identity provider. The identity provider verifies the user, issues a signed token confirming the authentication, and passes it back. The service provider trusts that token and grants access.

A typical SSO login flow looks like this:

1. A user navigates to a business application (the service provider).
2. The application redirects the user to the identity provider for authentication.
3. The identity provider checks whether the user is already signed in. If yes, it skips ahead. If no, it prompts for credentials, which may include a password, a second factor, or a passwordless authenticator.
4. The identity provider verifies the user and creates a signed authentication token.
5. The token is passed back to the service provider, which validates it against the trust relationship established during setup.
6. The user is granted access without entering credentials again.

When the same user moves to another connected application, that application redirects them to the identity provider. Because the provider already has an active session, it skips the login prompt and sends back a signed token confirming the user’s identity. This is what makes SSO feel like a single login, even though several systems are coordinating behind the scenes.

An SSO token is a small piece of signed data the identity provider sends to the service provider to confirm that a user has been authenticated. It usually contains information like the user’s identifier, the issuing identity provider, and the time the token was issued. Tokens are digitally signed using a certificate exchanged during initial configuration, which lets the service provider verify that the token actually came from a trusted source and has not been tampered with. Without that signature, an attacker could forge a token and impersonate any user, which is why token management and lifecycle controls matter as much as the underlying protocol.

SSO is not a single technology. It is built on a small number of well-defined protocols, each with its own strengths and typical use cases. Understanding the protocols helps when evaluating vendors and integrating with existing applications.

• SAML (Security Assertion Markup Language): An XML-based standard widely used for web-based SSO between enterprise applications. SAML is the most common protocol behind enterprise SSO for SaaS applications.
• OAuth 2.0: A framework for delegated authorization. OAuth allows one application to grant another limited access to a user’s data without sharing the user’s credentials. It is the foundation on which many modern web and mobile authentication flows are built.
• OpenID Connect (OIDC): An authentication layer built on top of OAuth 2.0. OIDC adds identity verification to OAuth’s authorization model and is widely used for SSO across cloud applications, mobile apps, and consumer-facing services.
• Kerberos: A network authentication protocol that uses symmetric key cryptography and a trusted third party to issue tickets that authenticate users across systems. Kerberos is common in on-premises Windows environments and is often a foundational layer for internal SSO.

Most enterprise SSO deployments use SAML or OIDC for cloud and web applications, with Kerberos or related directory protocols handling on-premises systems. A capable identity provider supports all of them so SSO can work consistently across the entire application portfolio.

SSO has become a workforce essential because it consolidates where security and operational decisions get made. Instead of every application owning its own login and policy logic, authentication happens in one place, policies are enforced once, and access can be granted or revoked across the portfolio from a single control point. 

• Fewer passwords: SSO reduces the number of passwords that users have to manage or reuse across applications. The best SSO solutions will allow for passwordless authentication into the SSO portal itself to eliminate passwords altogether. Centralized policy enforcement: Password rules, MFA requirements, session timeouts, and access policies are applied in one place instead of being configured per application.
• A single point for layering MFA: Adding MFA at the SSO layer extends stronger authentication to every connected application at once.
• Faster onboarding and offboarding: When a user joins or leaves the organization, access can be granted or revoked across all connected applications from a single control point.
• Less help desk burden: Fewer passwords mean fewer password resets, which frees IT for higher-value work.
• Better user experience: Employees spend less time signing in and more time getting work done.

SSO concentrates a lot of value in a single sign-in event, which is also where most of its risk sits. The same consolidation that makes SSO easier to manage means a compromised credential, a misconfigured trust relationship, or an outage at the identity provider can cascade across every connected application at once. That is not a reason to avoid SSO. It is the reason SSO needs to be designed and reinforced carefully.

• Single point of compromise: If an attacker compromises a user’s SSO credentials, they may gain access to every connected application. That makes the strength of the SSO sign-in itself critically important.
• Identity provider availability: If the identity provider goes down, users may be unable to sign in to connected applications. High availability and resilience are core requirements for any SSO deployment.
• Misconfiguration risk: SSO relies on trust relationships and certificates. Mistakes during setup, expired certificates, or poorly scoped permissions can create access gaps or expose applications.
• Recovery and fallback: A weak account recovery process can undo the security benefits of SSO. If a user can recover access through a weak help desk workflow, the strong front door does not matter.
• Not all applications support modern SSO: Legacy applications may not support SAML, OIDC, or Kerberos, which can force workarounds that weaken the overall posture.

SSO and other systems

The most important point about SSO risk is that SSO on its own is not enough. SSO confirms that the right credentials were entered. It does not, by itself, confirm that the right person entered them. That is why most enterprises pair SSO with autenticación multifactor, adaptive or risk-based policies, device posture checks, and identity governance. SSO and MFA are complementary: SSO simplifies the sign-in event, and MFA strengthens it. 

SSO is rarely deployed on its own. It works best as one layer inside a broader identity and access strategy, and where it fits matters as much as how it is configured.

SSO and IAM

SSO is a component of identity and access management, not a replacement for it. IAM is the broader discipline that covers who someone is, what they are allowed to do, and what happens to their access over time. SSO handles the authentication event itself, simplifying how users prove who they are across the application portfolio. A strong identity program uses SSO as the front door and IAM as the framework around it.

SSO and Zero Trust

Confianza cero assumes no user, device, or session should be trusted by default, even inside the corporate network. SSO supports that model by giving security teams a consistent place to verify users before access is granted, and by making it easier to enforce MFA, adaptive policies, and session controls at every sign-in. SSO on its own does not deliver Zero Trust, but it is one of the controls Zero Trust architectures depend on.

SSO and identity governance

Authentication confirms that a user is who they claim to be. Identity governance decides whether that user should have access in the first place, whether the access is still appropriate, and when it should be revoked. SSO and gobernanza de la identidad work together: SSO is the access layer, governance is the oversight layer that keeps the access layer aligned with policy, risk, and compliance requirements over time.

Implementing SSO is part technology project and part identity strategy decision. The technology side involves selecting an identity provider, defining trust relationships with each application, configuring user directories, and rolling out authentication policies. The strategy side involves deciding which applications belong inside the SSO perimeter, how recovery and exception handling will work, and how SSO will interact with MFA and governance.

A practical implementation usually moves through these steps:

1. Inventory the applications that should be brought under SSO, prioritizing high-value and high-risk systems first.
2. Choose an identity provider that supports the protocols those applications use (typically SAML, OIDC, and Kerberos).
3. Connect the identity provider to authoritative user directories so identities, attributes, and group memberships flow consistently.
4. Configure trust relationships, certificates, and attribute mapping for each application.
5. Define authentication policies, including MFA requirements, session length, and adaptive risk signals.
6. Pilot with a small user group, then roll out in phases.
7. Establish ongoing processes for adding new applications, rotating certificates, and reviewing access.

Choosing an SSO vendor is mostly about fit with the environment the vendor will be deployed into. A few criteria matter more than others:

• Broad protocol support: SAML, OIDC, OAuth 2.0, and Kerberos at minimum, so the SSO layer can cover both modern SaaS and legacy on-premises applications.
• Strong authentication options: Native MFA, adaptive authentication, and passwordless support, so SSO is not the weak link in the chain.
• Deployment flexibility: Cloud, hybrid, on-premises, and high-assurance options for organizations that operate across regulated or sovereign environments.
• Integration with identity governance: SSO should connect to identity lifecycle, access reviews, and policy management, not stand apart from them.
• Resilience and availability: High-availability architecture and clear disaster recovery posture, since SSO sits in the critical path for workforce access.
• A clear roadmap toward passwordless: SSO is often the first step in modernizing authentication, and the vendor should be able to support the next steps.

SSO is one of the highest-leverage controls in an identity program. It simplifies access for users, gives security teams a single point to apply stronger policies, and creates the foundation for MFA, adaptive authentication, and passwordless authentication. But the value of SSO depends on the strength of the sign-in behind it, the protocols it supports, and how well it integrates with the rest of the identity stack.

RSA helps organizations deliver SSO as part of a complete identity strategy, with the authentication, governance, and deployment flexibility enterprises need across cloud, hybrid, on-premises, and high-assurance environments. To see how it fits your organization, explore RSA single sign-on y identity management solutions.