--- term: 'Single Sign-On (SSO)' seoTitle: 'Single Sign-On (SSO): cómo funciona, SAML vs. OIDC, riesgos' headline: '¿Qué es el Single Sign-On (SSO)?' slug: single-sign-on-sso category: auth-security shortDefinition: 'El single sign-on es un método de autenticación en el que un solo login en el proveedor de identidad da acceso a muchas aplicaciones independientes.' relatedTerms: - identity-access-management-iam - oauth-2-social-login - multi-factor-authentication-mfa - session-management contrastsWith: - oauth-2-social-login aboutTerms: - 'Proveedor de Identidad (IdP)' - 'Service Provider (SP)' - 'SAML' - 'Single Logout (SLO)' faq: - question: '¿Qué es el SSO en términos simples?' answer: 'Un login desbloquea muchas apps: pruebas quién eres una vez ante un proveedor de identidad central, y cada aplicación conectada confía en esa prueba en lugar de pedir su propia contraseña. El login matutino al portal de la empresa que abre en silencio el correo, la wiki y el CRM es el SSO en acción.' - question: '¿Cómo funciona el SSO?' answer: 'Con redirects y tokens firmados. La app envía al usuario no autenticado al proveedor de identidad; el usuario se autentica allá — contraseña más MFA — y el IdP emite una aserción firmada digitalmente que el navegador lleva de vuelta; la app valida la firma contra certificados intercambiados de antemano e inicia una sesión. La siguiente app se salta el login porque la sesión del IdP ya existe.' - question: '¿Es seguro el SSO?' answer: 'Positivo en el neto cuando el proveedor de identidad impone MFA: existen menos contraseñas que phishear, y las políticas, la auditoría y el bloqueo viven en un solo lugar. El costo honesto es la concentración — una cuenta comprometida en el IdP, o el IdP mismo, abre todo lo que hay río abajo. El SSO vuelve la puerta de entrada excelente y única.' - question: '¿Cuál es la diferencia entre SSO y un gestor de contraseñas?' answer: 'Un gestor de contraseñas guarda muchos secretos y los autocompleta — cada app sigue corriendo su propio login. El SSO elimina las contraseñas por app: las apps delegan la autenticación al IdP y no guardan ninguna credencial tuya. Se complementan; los gestores cubren la cola larga de apps sin soporte de SSO.' - question: '¿El login social es lo mismo que el SSO?' answer: 'La misma maquinaria, distinto casero. Ambos son flujos de redirect al estilo OIDC hacia un proveedor de identidad — pero el login social usa el IdP de una plataforma de consumo para entrar a una sola app, mientras que el SSO empresarial usa un IdP controlado por la organización cuya sesión única abarca toda una suite de aplicaciones.' - question: '¿SAML u OIDC para SSO?' answer: 'OIDC para todo lo nuevo — JSON y JWTs sobre REST, amigable con mobile y SPAs, más fácil de implementar y depurar. SAML por compatibilidad — el protocolo de la era XML atrincherado en los proveedores de identidad empresariales. Los productos que venden a empresas suelen terminar hablando ambos.' - question: '¿Sigo necesitando MFA con SSO?' answer: 'Enfáticamente — el SSO vuelve ese único login más valioso, no menos. La virtud compensatoria: imponer MFA en el proveedor de identidad protege todas las aplicaciones conectadas en un solo movimiento, que es precisamente la centralización que el SSO existe para ofrecer.' - question: '¿Qué pasa cuando el proveedor de identidad se cae?' answer: 'Nadie inicia una sesión nueva en ninguna app conectada — las sesiones existentes de cada app sobreviven hasta expirar. Esta es la cara de disponibilidad del punto único de falla, y la razón por la que la redundancia del IdP, las cuentas de administrador de emergencia y los caminos alternativos pertenecen al plan de despliegue, no al postmortem.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'SAML 2.0 Technical Overview — OASIS' url: 'https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html' - name: 'OpenID Connect Core 1.0' url: 'https://openid.net/specs/openid-connect-core-1_0.html' - name: 'NIST SP 800-63C — Federation and Assertions' url: 'https://pages.nist.gov/800-63-3/sp800-63c.html' - name: 'RFC 6749 — The OAuth 2.0 Authorization Framework' url: 'https://datatracker.ietf.org/doc/html/rfc6749' cta: title: 'Login empresarial, a un adaptador de distancia' text: 'Apunta los adaptadores de autenticación de Back4app al proveedor de identidad de tu cliente — Keycloak, LDAP o cualquier emisor OIDC — y Back4app verifica sus tokens del lado del servidor, mapea identidades a usuarios y emite las sesiones de tu app.' linkText: 'Empieza gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-08-31' translationKey: single-sign-on-sso --- **El single sign-on es un método de autenticación en el que un solo login en el proveedor de identidad da acceso a muchas aplicaciones independientes.** El elenco tiene dos roles: el **proveedor de identidad (IdP)** autentica a los usuarios y responde por ellos; cada **service provider (SP)** — las apps que de verdad quieres usar — confía en ese aval en lugar de correr su propio login. Una distinción pedante que vale la pena guardar: apps que comparten un directorio pero piden la contraseña una por una son *same* sign-on — el mismo login, varias veces; el SSO de verdad significa que te pregunten una sola vez. ## Puntos clave | Pregunta | Respuesta | | --- | --- | | El elenco | El IdP autentica y avala · los SPs confían en el aval | | El mecanismo | Redirects + aserciones firmadas — la contraseña nunca sale del IdP | | Los protocolos | SAML (XML, legado empresarial) · OIDC (JWT sobre OAuth, el default moderno) | | El trade-off | Una puerta de entrada excelente — y una sola puerta que vale todo lo que hay detrás | | La letra chica | El single logout es difícil · las sesiones corren en varios relojes · el SSO cuesta extra en SaaS | ## La danza de redirects, paso a paso ¿Por qué redirects, para empezar? La política de mismo origen del navegador: `app.example.com` no puede leer una cookie de login de `idp.example.org`, así que la identidad debe viajar *como un mensaje firmado a través del navegador* y no como una cookie compartida — que es exactamente lo que hace el flujo: ```text 1 El usuario abre app.example.com — sin sesión 2 El SP redirige al IdP con una solicitud de autenticación 3 El usuario se autentica EN EL IDP (contraseña + MFA) — o ya tiene una sesión en el IdP, y este paso se salta en silencio 4 El IdP emite una aserción firmada (XML de SAML) o un ID token (JWT de OIDC) 5 El navegador la entrega en la URL de callback del SP 6 El SP valida: firma · issuer · audience · expiración · replay 7 El SP inicia su propia sesión local — el usuario está dentro 8 Siguiente app: pasos 1–2, y luego directo del camino silencioso del 3 al 7 ``` Así se ve el lado del service provider cuando un backend lo envuelve: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Enterprise SSO: the IdP authenticates; the app trusts its signed token // After the OIDC redirect dance, the client holds the IdP's tokens: const user = await Parse.User.logInWith('keycloak', { authData: { id: subClaim, // the IdP's stable subject ID access_token: accessToken, // verified server-side against the IdP }, }); // One IdP login now serves every app that trusts the same issuer. ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Enterprise SSO: the IdP authenticates; the app trusts its signed token // After the OIDC redirect dance, the client holds the IdP's tokens: final user = ParseUser.forQuery(); final response = await user.loginWith('keycloak', { 'id': subClaim, // the IdP's stable subject ID 'access_token': accessToken, // verified server-side against the IdP }); // One IdP login now serves every app that trusts the same issuer. ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Enterprise SSO: the IdP authenticates; the app trusts its signed token // After the OIDC redirect dance, the client holds the IdP's tokens: let user = try await User.loginWith( "keycloak", authData: [ "id": subClaim, // the IdP's stable subject ID "access_token": accessToken // verified server-side against the IdP ] ) // One IdP login now serves every app that trusts the same issuer. ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Enterprise SSO: the IdP authenticates; the app trusts its signed token // After the OIDC redirect dance, the client holds the IdP's tokens: val authData = mapOf( "id" to subClaim, // the IdP's stable subject ID "access_token" to accessToken // verified server-side against the IdP ) ParseUser.logInWithInBackground("keycloak", authData).continueWith { task -> val user = task.result // One IdP login now serves every app that trusts the same issuer. } ``` ```mermaid flowchart LR accTitle: Flujo de single sign-on entre service providers y el proveedor de identidad accDescr: Un usuario no autenticado en un service provider es redirigido al proveedor de identidad, se autentica una vez con MFA y recibe una aserción firmada entregada de vuelta al service provider, que la valida e inicia una sesión local. Una segunda aplicación repite el redirect, pero la sesión existente en el proveedor de identidad vuelve el login silencioso. U["Usuario"] --> SP1["App A (SP)
sin sesión"] SP1 -->|"redirect + solicitud de auth"| IDP["Proveedor de identidad
login + MFA · sesión global"] IDP -->|"aserción firmada"| SP1 SP1 -->|"valida → sesión local"| OK1["App A abierta"] U2["El mismo usuario, después"] --> SP2["App B (SP)"] SP2 -->|"redirect"| IDP IDP -.->|"la sesión existe —
aserción silenciosa"| SP2 --> OK2["App B abierta,
sin pantalla de login"] ``` ## Iniciado por el SP vs. iniciado por el IdP | | Iniciado por el SP | Iniciado por el IdP | | --- | --- | --- | | Empieza en | La app ("Iniciar sesión con SSO") | El mosaico del panel del IdP | | Solicitud | El SP emite una solicitud de autenticación | Ninguna — la aserción llega sin ser pedida | | Vínculo de la respuesta | La aserción responde a una solicitud específica | No hay solicitud contra la cual cotejar | | Postura de seguridad | El default — las verificaciones de replay se anclan en la solicitud | Históricamente más débil; las aserciones no solicitadas invitan inyección | | ¿Soportarlo? | Siempre | Solo donde el IdP lo exija, con validación extra | La mayoría de los explicadores describe solo el primero y nunca nombra el segundo — pero a los IdPs empresariales les encantan los mosaicos de panel, así que los SPs se encuentran con ambos. El [panorama técnico de SAML](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html) especifica los dos perfiles; la regla práctica está en la última fila de la tabla. ## SAML vs. OIDC | | SAML 2.0 | OpenID Connect | | --- | --- | --- | | Era y formato | 2005 · aserciones XML | 2014 · [JWTs](/glossary/es/json-web-token-jwt/) sobre [OAuth 2.0](/glossary/es/oauth-2-login-social/) | | Transporte | Bindings de POST/redirect en el navegador | REST + redirects | | Encaja con | Apps web empresariales, IdPs legados | Mobile, SPAs, APIs — todo lo actual | | Experiencia de desarrollo | Verboso, frágil, dependiente de bibliotecas | Tokens legibles, flujos estándar | | Veredicto | Sopórtalo porque los IdPs de tus clientes lo hablan | Elígelo para todo lo nuevo | Y el triángulo que desenreda las siglas, de una vez: **SAML y OIDC hacen autenticación para el SSO; [OAuth 2.0 solo es autorización](/glossary/es/autenticacion-vs-autorizacion/)** — OIDC es la capa de identidad que volvió la plomería de OAuth segura para iniciar sesión. El login social es la misma maquinaria OIDC con una plataforma de consumo como IdP y una sola app como audiencia; el SSO empresarial cambia de casero y ensancha la sesión a una suite. ## Las partes que nadie menciona **El single logout (SLO) es la mitad difícil.** El login converge *hacia adentro*, a un IdP; el logout debe abrirse *hacia afuera*, a cada SP con sesión local — y la cadena se rompe si una app no responde, las restricciones de cookies de terceros de los navegadores rompen las notificaciones de front-channel, y nada llega a tus otros dispositivos. En la práctica, "cerré sesión en todas partes" significa sesiones locales cortas que re-verifican la sesión (terminada) del IdP, no un broadcast confiable. **Las sesiones corren en tres relojes:** la sesión global del IdP, la [sesión](/glossary/es/gestion-de-sesiones/) local de cada app y la ventana de validez de la propia aserción. Cerrar sesión en una app mientras la sesión del IdP vive significa reingreso silencioso en la siguiente visita — comportamiento que los usuarios reportan como bug y que los arquitectos deberían reconocer como el diseño. **Y el impuesto del SSO:** los proveedores de SaaS rutinariamente encierran el soporte de SAML/SSO detrás de planes enterprise a múltiplos del precio base — un hecho de mercado que merece presupuesto, ya que el requisito del equipo de seguridad y la línea de compras llegan juntos. ## El radio de impacto, con honestidad El SSO concentra el riesgo a propósito — eso es lo que "single" significa. Una cuenta comprometida en el IdP abre todas las apps conectadas; un IdP comprometido *en sí* — incluido el robo de sus claves de firma de aserciones, el patrón de ataque de la "aserción dorada" — acuña identidad válida para cualquiera, en cualquier parte. Los proveedores lo suavizan; la respuesta de ingeniería es gastar bien la concentración: **[MFA](/glossary/es/autenticacion-multifactor-mfa/) resistente al phishing en el IdP** (ese único login ahora vale protección de nivel passkey), **autenticación step-up** para las apps sensibles en lugar de una sesión-manta, **sesiones globales cortas** donde el riesgo es alto, rotación y monitoreo de las claves de firma, y cuentas locales de emergencia para el día en que el IdP se caiga. El punto único de falla nunca desaparece — se blinda, porque blindar un solo punto es exactamente la economía que el SSO prometió. ## Integrarse como service provider Lo que "soportamos SSO" exige de verdad de un equipo de aplicación, en una lista: registra tu URL de callback/ACS en el IdP e intercambia metadatos (issuer, certificados); valida todo en cada aserción — firma, issuer, audience, expiración y vínculo anti-replay; mapea los claims del IdP a tu modelo de usuario, anclado en el subject estable, nunca en el email solo; provisiona just-in-time (el primer login por SSO crea el usuario local); maneja las llegadas iniciadas por el IdP de forma deliberada; y prueba las expectativas de logout contra la realidad de los tres relojes de arriba. Es un camino bien recorrido — por eso existen IdPs open-source como Keycloak para el otro lado del apretón de manos — pero cada punto que se salte es un hallazgo de seguridad con fecha marcada. ## Casos de uso comunes - **Suites de apps corporativas** — el caso canónico: un login por la mañana, todas las herramientas internas y SaaS después. - **SaaS B2B subiendo de mercado** — "soporta SSO" como el checkbox que destraba el contrato enterprise. - **Educación y salud** — acceso federado entre instituciones, donde las raíces de SAML son más profundas. - **MFA y offboarding centralizados** — un solo lugar para imponer factores; un interruptor que termina en todas partes el acceso del empleado que se fue. - **Productos multi-app** — tu propia suite compartiendo un login vía tu propio IdP, al estilo consumidor. ## ¿Deberías agregar SSO? Matriz de decisión | Situación | Inclinación | | --- | --- | | Vendes a empresas | Sí — OIDC + SAML; destraba contratos | | Herramientas internas detrás de un IdP corporativo | Sí — centraliza MFA y offboarding | | App de consumo | [Login social](/glossary/es/oauth-2-login-social/) — la misma maquinaria, IdPs de consumo | | Una app, equipo pequeño | Sesiones + MFA alcanzan; revísalo en la tercera app | | Apps de alta criticidad detrás del SSO | Agrega step-up — no te subas a la sesión-manta | | Eliges un protocolo hoy | OIDC primero; SAML para los clientes que lo exijan | ## Limitaciones y trade-offs - **La disponibilidad se concentra junto con la identidad.** La caída del IdP es la caída del login de todos; la redundancia y los caminos de emergencia son parte de la funcionalidad, no adiciones a ella. - **El logout es más débil que el login.** El fan-out del SLO falla parcialmente por diseño; sesiones locales cortas, no broadcasts de logout, entregan la garantía real. - **La cola larga sigue con contraseña.** Las apps sin soporte de SSO conservan sus propias credenciales — los gestores de contraseñas siguen siendo la capa de limpieza. - **Las capas de sesión confunden a los usuarios.** El relogin silencioso y los tickets de "cerré sesión pero no" son la factura de UX del diseño de tres relojes; la documentación y los timeouts predecibles la amortizan. - **La calidad de integración varía por SP.** El techo de seguridad del SSO lo fija la validación de aserciones más descuidada entre tus apps conectadas — la lista de arriba es por app, para siempre. ## SSO en Back4app Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Una app aquí se suma a un parque de SSO como service provider mediante el mismo mecanismo de adaptadores que impulsa el [login social](/glossary/es/oauth-2-login-social/): Back4app trae adaptadores de autenticación para Keycloak, LDAP y emisores OAuth2/OIDC genéricos, así que el flujo de las pestañas de código — el IdP autentica, la app recibe tokens, `logInWith` los verifica del lado del servidor contra el emisor — convierte el SSO empresarial en configuración más un handler de redirect. Las identidades se anclan en el subject estable del IdP en bloques `authData` por proveedor, el primer login provisiona al usuario just-in-time, `linkWith` acopla métodos adicionales para el camino de emergencia, y la sesión que tu app emite sigue siendo una sesión Parse revocable — de modo que la pila de tres relojes termina, de tu lado, con un reloj que controlas por completo.