7 pasos para el inicio de sesión único en aplicaciones personalizadas para ingenieros y gerentes de producto
7 pasos para el inicio de sesión único en aplicaciones personalizadas para ingenieros y gerentes de producto Para nuevas aplicaciones web o móviles personalizadas, use OpenID Connect con el flujo de código de autorización más PKCE; reserve SAML para casos en los que deba interoperar con proveedores de identidad empresariales heredados.
Para nuevas aplicaciones web o móviles personalizadas, use OpenID Connect con el flujo de código de autorización más PKCE; reserve SAML para casos en los que deba interoperar con proveedores de identidad empresariales heredados. Antes de escribir cualquier código, tenga listo lo siguiente: un URI de redirección registrado, un ID de cliente, una URL de emisor o metadatos, y acceso al endpoint JWKS del proveedor. Confirme que PKCE usa el método S256, que los tokens están limitados a una sola audiencia, y que tanto los parámetros nonce como state se validan en la devolución de llamada.
Resumen:
- Use OpenID Connect con código de autorización y PKCE para nuevas aplicaciones nativas en la nube, reservando SAML solo para integraciones empresariales heredadas.
- Confirme la validación completa de PKCE, la restricción de audiencia del token, y valide los parámetros nonce y state en cada devolución de llamada para garantizar la seguridad.
- Soporte ambos protocolos cuando sea necesario, pero use OIDC por defecto para aplicaciones modernas, especialmente con arquitecturas de API y móviles, mientras soporta SAML para socios empresariales.
- Registre correctamente las aplicaciones, valide el emisor y JWKS, y pruebe la validez del token y la sincronización del reloj antes del despliegue en producción; mantenga entornos de staging y producción separados.
- Implemente una validación cuidadosa del cierre de sesión, supervise errores comunes como discrepancias en el URI de redirección, y prepárese para rotaciones de certificados con manuales operativos detallados.
Tabla de contenidos
- Elección entre OIDC y SAML para aplicaciones personalizadas
- Implementación paso a paso de OpenID Connect para aplicaciones personalizadas
- Integración de SAML 2.0 para proveedores de identidad empresariales
- Cómo hacer bien el código de autorización más PKCE
- Dónde deben vivir los tokens: patrones BFF, SPA y móviles
- Manejo correcto del cierre de sesión y la terminación de sesión
- Lista de verificación de pruebas y errores comunes en el despliegue de SSO
- Estándares de seguridad que toda revisión de diseño de SSO debería referenciar
- Una lista de verificación operativa basada en trabajo de entrega
- Obtén ayuda para implementar SSO en tu aplicación personalizada
- Fuentes
- Preguntas frecuentes
Elección entre OIDC y SAML para aplicaciones personalizadas
La decisión del protocolo generalmente se reduce a qué tipo de aplicación estás construyendo y con quién necesitas comunicarte. OpenID Connect se recomienda para aplicaciones nuevas y nativas en la nube, ya que se construye sobre OAuth 2.0 y está diseñado para encajar naturalmente en arquitecturas web y de API. SAML 2.0 sigue siendo común en integraciones B2B empresariales, especialmente cuando el proveedor de identidad tiene décadas de antigüedad y el equipo de integración no tiene planes de modernizarlo.
Las ventajas y desventajas son prácticas, no filosóficas. SAML depende del intercambio de metadatos XML y la confianza basada en certificados, lo que significa que la rotación de certificados y el mapeo de atributos se convierten en tareas de mantenimiento recurrentes. OIDC se apoya en tokens web JSON y un documento de descubrimiento, que la mayoría de las bibliotecas actuales manejan con mucho menos código personalizado.
Algunas cosas a considerar antes de comprometerte con un protocolo en toda tu aplicación:
- Arquitectura de la aplicación: Las aplicaciones de una sola página, las aplicaciones móviles y los backends centrados en API encajan más naturalmente con el modelo de tokens de OIDC que con las suposiciones de redirección del navegador de SAML.
- Panorama de IdP de socios: Si tus clientes empresariales solo exponen endpoints SAML, tendrás que soportarlo independientemente de tu propia preferencia.
- Complejidad multiinquilino: Planifica la búsqueda del emisor, la verificación de dominio y el descubrimiento de dominio de origen desde el principio si vas a soportar múltiples IdP de clientes, ya que adaptar el enrutamiento de inquilinos después del lanzamiento es doloroso.
La mayoría de los equipos terminan soportando ambos, con OIDC como predeterminado y SAML como una adaptación para cuentas empresariales específicas.
Implementación paso a paso de OpenID Connect para aplicaciones personalizadas
Una vez que te has decidido por OIDC, la secuencia de implementación es bastante consistente entre proveedores, ya sea que uses Okta, Azure AD u otra plataforma de identidad.
- Registra la aplicación con tu proveedor de identidad, especificando el tipo de cliente (público o confidencial), las URI de redirección exactas y los orígenes permitidos para CORS.
- Obtén el documento de descubrimiento desde el
/.well-known/openid-configurationdel proveedor y almacena en caché las URL del emisor y de JWKS. - Valida el emisor en cada token que recibas, comparándolo exactamente con el valor del documento de descubrimiento.
- Solicita el
openidscope como mínimo, añadiendoprofileoemailsolo si tu aplicación realmente necesita esas afirmaciones. - Inicia el flujo de Código de Autorización con PKCE, generando un verificador de código y un desafío de código con hash S256 antes de redirigir al usuario.
- Valida el
id_tokendevuelto, comprobandoiss,aud,exp, y elnonceque generaste al inicio del flujo, como recomienda la guía de OAuth2 de OWASP. - Maneja los secretos de manera adecuada: los clientes confidenciales almacenan el secreto del cliente solo en el servidor; los clientes públicos dependen completamente de PKCE en su lugar.
Algunos detalles de despliegue causan problemas a los equipos que omiten los entornos de staging: las listas de permitidos de URI de redirección son de coincidencia exacta en la mayoría de los proveedores, por lo que una discrepancia en la barra final fallará silenciosamente o lanzará un error críptico. El desfase de reloj entre tu servidor y el IdP puede hacer que tokens válidos sean rechazados como caducados. Prueba contra un inquilino de IdP de staging con su propio registro de cliente antes de tocar las credenciales de producción.
Consejo profesional: Mantén registros de cliente separados para staging y producción, incluso si significa duplicar el trabajo de configuración: compartir una lista de permitidos de URI de redirección entre entornos es una fuente común de sorpresas de “funcionó en staging”.
Integración de SAML 2.0 para proveedores de identidad empresariales
Las integraciones SAML siguen un ritmo diferente, basado en el intercambio de metadatos en lugar de endpoints de descubrimiento. Configurar SSO con SAML requiere registrar las URL de redirección y ACS, intercambiar metadatos o certificados, y alinear los valores del emisor entre el proveedor de servicios y el proveedor de identidad, y las discrepancias aquí son la causa más frecuente de fallos de inicio de sesión.
Pasos prácticos para una integración limpia:
- Intercambiar metadatos de SP e IdP desde el principio, incluida la URL del Servicio de Consumidor de Aserciones (ACS) y tu Entity ID, para que ambas partes acuerden a dónde se envían las aserciones.
- Gestionar los certificados de forma deliberada: extráelos del endpoint de metadatos del IdP cuando esté disponible en lugar de codificar un certificado que eventualmente caducará.
- Mapear atributos SAML en el modelo de autorización de tu aplicación usando una lista blanca explícita, y prueba el mapeo con un usuario de prueba dedicado por inquilino antes de implementarlo en cuentas reales.
Los fallos específicos de SAML tienden a agruparse en torno a un puñado de causas: aserciones sin firmar o firmadas incorrectamente, desfase de reloj entre el IdP y tu servidor, y desajustes en la restricción de audiencia donde el destinatario previsto de la aserción no coincide con tu Entity ID.
Consejo profesional: Registra la respuesta SAML sin procesar (excluyendo valores de atributos sensibles) durante las pruebas de integración. Los problemas de espacios de nombres XML son mucho más fáciles de detectar en un payload sin procesar que en un seguimiento de pila a tres capas de distancia de la aserción real.
Implementar correctamente el Código de Autorización con PKCE
PKCE existe para cerrar una brecha específica: sin él, un código de autorización interceptado puede ser canjeado por quien lo haya capturado. PKCE vincula la solicitud de autorización inicial con el intercambio de tokens mediante un verificador, de modo que incluso un código robado es inútil sin el verificador correspondiente. El flujo de Código de Autorización con PKCE es ahora la práctica de seguridad básica para clientes públicos, con S256 como el método recomendado para el desafío de código sobre el método simple más débil.
La mecánica es sencilla una vez que la has implementado: genera un verificador de código aleatorio, aplícale un hash SHA-256 para producir el desafío de código, envía el desafío en la solicitud de autorización y presenta el verificador original al intercambiar el código por tokens. Las partes donde los equipos se equivocan:
- Omitir la validación del nonce, lo que anula una de las principales protecciones contra ataques de repetición en la capa OIDC.
- Permitir la reutilización del código, cuando un código debe ser de un solo uso e invalidarse inmediatamente después del primer intento de intercambio.
- Almacenar el verificador de forma insegura, como en un lugar accesible para cualquier script que se ejecute en la página en una aplicación basada en navegador.
Los clientes confidenciales, es decir, aplicaciones de servidor que pueden guardar un secreto de forma segura, aún combinan PKCE con un secreto de cliente en muchas implementaciones. Los clientes públicos como SPAs y aplicaciones móviles nativas dependen solo de PKCE, ya que no pueden mantener un secreto confidencial.
Dónde deben vivir los tokens: patrones BFF, SPA y móvil
La ubicación de los tokens determina la mayor parte de la exposición de tu aplicación al robo de tokens. El patrón backend-para-frontend mantiene los tokens en el servidor y emite al navegador una cookie HttpOnly de corta duración en su lugar, una configuración que se ha convertido en la recomendación estándar para aplicaciones de una sola página que llaman a APIs privadas.
RFC 9700 describe los tokens vinculados criptográficamente y restringidos al remitente como una dirección emergente para reducir el riesgo de repetición, lo que indica que las decisiones de diseño de manejo de tokens hoy deben considerar posibles requisitos de vinculación más estrictos.
Reglas prácticas para la topología de tokens:
- Clientes confidenciales guardan secretos en el servidor; clientes públicos dependen de PKCE y tokens de acceso de corta duración en lugar de un secreto.
- Limita los tokens de acceso a una sola audiencia para cada API, y nunca aceptes un token de ID como si fuera un token de acceso a la API.
- Rota los tokens de actualización en cada uso y detecta la reutilización de un token retirado como señal de posible robo.
Las aplicaciones móviles generalmente siguen el modelo de cliente público, almacenando tokens en el almacenamiento seguro proporcionado por la plataforma (Keychain en iOS, Keystore en Android) en lugar de archivos simples.
Manejar correctamente el cierre de sesión y la terminación de sesión
El cierre de sesión único suena simple hasta que consideras quién lo inició y hasta dónde debe propagarse. En el cierre de sesión iniciado por SP, tu aplicación le dice al IdP que el usuario ha terminado; en el cierre de sesión iniciado por IdP, el IdP les dice a todas las aplicaciones conectadas que terminen la sesión. Ambas direcciones requieren validar el mensaje entrante.
El Cierre de Sesión Único de SAML requiere una validación cuidadosa de las solicitudes de cierre de sesión, ya que las implementaciones ingenuas exponen riesgos de denegación de servicio o cierre forzado de sesión donde un atacante envía un mensaje de cierre de sesión no autenticado para expulsar a un usuario legítimo.
Construye el cierre de sesión con estas protecciones:
- Valida cada solicitud de cierre de sesión en cuanto a firma y
id_token_hintantes de actuar sobre él. - Tratar el cierre de sesión global como un esfuerzo máximo: limpiar la sesión local de inmediato y luego intentar notificaciones posteriores en lugar de bloquearse en ellas.
- Para SAML específicamente, exigir solicitudes de cierre de sesión firmadas y configurar el endpoint SLO explícitamente en lugar de asumir uno predeterminado.
Lista de verificación de pruebas y errores comunes en el despliegue de SSO
Antes del lanzamiento, revisa una breve lista de verificación previa en lugar de descubrir problemas en producción.
- Confirmar que las URI de redirección coincidan exactamente, incluyendo barras finales y protocolo.
- Verificar que el emisor y los metadatos estén alineados entre la configuración de tu aplicación y lo que el IdP realmente publica.
- Comprobar la disponibilidad de JWKS y confirmar que tu aplicación puede obtener y almacenar en caché las claves de firma.
- Sincronizar los relojes del servidor, ya que incluso unos pocos minutos de desviación causan fallos en la validación de tokens.
- Probar con un inquilino de IdP de ensayo usando cuentas dedicadas antes de tocar credenciales de producción.
Los errores comunes se corresponden con correcciones específicas: invalid_redirect_uri casi siempre significa una discrepancia de coincidencia exacta en la lista de permitidos, y la discrepancia del emisor suele significar que tu aplicación almacenó en caché un documento de descubrimiento obsoleto. Registra eventos de autenticación, incluidos fallos e intentos de reutilización, sin almacenar nunca tokens sin procesar en los registros.
Estándares de seguridad que toda revisión de diseño de SSO debería consultar
Un puñado de documentos deberían anclar cualquier revisión de diseño o seguridad de SSO. RFC 9700 establece la línea base de seguridad actual de OAuth 2.0, y RFC 7636 define el mecanismo PKCE del que depende esa línea base. La guía de OAuth y OIDC de OWASP ASVS trata la capa de OAuth y OIDC como un perímetro de seguridad que merece ser auditado por sí mismo.
Controles que vale la pena exigir en cada revisión:
- Restringir la audiencia de cada token y rechazar en el servidor de recursos los tokens que no fueron emitidos para él.
- Preferir una autenticación de cliente más sólida como private_key_jwt o TLS mutuo en lugar de secretos compartidos cuando tu proveedor lo admita.
- Rotar certificados y tokens de actualización según un calendario, e implementar revocación y detección de reproducción en lugar de depender solo de la caducidad del token.
Consejo profesional: Configura una alerta de calendario 30 días antes de que caduque cualquier certificado SAML. La caducidad de certificados es una interrupción evitable, no una sorpresa.
Una lista de verificación operativa basada en trabajo de entrega
Conseguir que el SSO funcione en una demo es la parte fácil. Conseguir que sobreviva a un lanzamiento en producción, una rotación de certificados y una caída del IdP seis meses después requiere un poco más de disciplina.
- Separar completamente el entorno de ensayo y el de producción, con registros de cliente distintos, cuentas de usuario de prueba y endpoints de metadatos.
- Crear un manual de rotación de certificados con ventanas de superposición y alertas 30 días antes de la caducidad, automatizando la ingesta desde los endpoints de metadatos cuando el proveedor lo admita.
- Entregar documentación real, incluyendo un manual de revocación de tokens, paneles de monitoreo para fallos de autenticación y scripts de pruebas de aceptación que el equipo del cliente pueda volver a ejecutar después de cualquier cambio.
Los equipos que omiten los documentos de traspaso tienden a reaprender estas lecciones durante un incidente en lugar de durante una tranquila tarde de martes.
Obtén ayuda para implementar SSO en tu aplicación personalizada
Si tu equipo tiene el diseño trazado pero necesita manos para construirlo, Ridiculous Engineering se encarga de todo el arco: revisión de arquitectura, implementación de OIDC o SAML, pruebas contra inquilinos de IdP de staging, y la configuración del runbook y monitoreo que lo mantiene funcionando después del lanzamiento. Trabajamos a través de desarrollo de software personalizado compromisos dimensionados al problema, no una plantilla fija, y preferimos explicar una compensación honestamente antes que vender un atajo de más. Si estás sopesando si construir esto internamente o traer a un equipo que ya haya lidiado con los dolores de cabeza de la rotación de certificados y los desajustes de URL de devolución de llamada, comunícate a través de nuestra página de contacto y hablaremos sobre lo que tu aplicación realmente necesita.
Fuentes
- RFC 9700: OAuth 2.0 Security Best Current Practice
- Microsoft Entra single sign-on (SSO)
- OAuth2 - OWASP Cheat Sheet Series
Preguntas frecuentes
¿Cómo creo mi propio SSO?
Implementas SSO integrando tu aplicación con un proveedor de identidad usando OpenID Connect o SAML en lugar de construir la autenticación desde cero. Para aplicaciones nuevas, OpenID Connect con el flujo de Código de Autorización y PKCE es el punto de partida estándar, manejado a través de SDKs de proveedores como los de Okta o Azure AD.
¿Es arriesgado el SSO?
El SSO no es inherentemente más arriesgado que los inicios de sesión específicos de la aplicación, y típicamente reduce el riesgo al consolidar la autenticación detrás de un proveedor con controles de seguridad más fuertes de los que la mayoría de las aplicaciones individuales podrían construir por sí solas. El riesgo real radica en errores de implementación como omitir PKCE, no validar la audiencia del token, o manejar mal el cierre de sesión, todo lo cual la guía de OAuth2 de OWASP aborda directamente.
¿Puedes hacer SSO en una aplicación móvil?
Sí, las aplicaciones móviles comúnmente implementan SSO como clientes públicos de OAuth 2.0 usando el flujo de Código de Autorización con PKCE, ya que no pueden almacenar de forma segura un secreto de cliente. Los tokens se almacenan típicamente en almacenamiento seguro nativo de la plataforma en lugar de archivos simples de la aplicación.
¿Quiénes son los principales proveedores de SSO?
Los proveedores de identidad comunes utilizados para integraciones de SSO incluyen Okta y Azure AD de Microsoft (ahora parte de Microsoft Entra), entre otros. La elección correcta depende de qué protocolos necesita soportar tu aplicación y qué proveedores ya utilizan tus clientes empresariales.
¿Cómo funciona el cierre de sesión único entre aplicaciones?
El cierre de sesión único puede ser iniciado por tu aplicación (iniciado por SP) o por el proveedor de identidad (iniciado por IdP), y ambos requieren validar el mensaje de cierre de sesión antes de actuar sobre él. Las implementaciones ingenuas de cierre de sesión SAML pueden exponer riesgos de denegación de servicio o de cierre forzado, por lo que la mayoría de los equipos tratan el cierre de sesión global como un mejor esfuerzo en lugar de un interruptor de apagado instantáneo garantizado en todas las aplicaciones conectadas.