Desfragmenta los accesos multidominio

Eiji Kitamura

Las arquitecturas empresariales modernas suelen abarcar varios dominios distintos. Las organizaciones mantienen entornos dedicados para diferentes funciones, como brand.example para marketing, service-app.example para el producto principal y support-portal.example para atención al cliente. Lo ideal es que proporciones una experiencia de acceso unificada y única a medida que los usuarios navegan por estas propiedades. Sin embargo, los equipos de ingeniería suelen integrar estos dominios con técnicas ad hoc que causan fragmentación. Esto interrumpe la administración de credenciales integrada en el navegador, ya que interrumpe los flujos de autocompletar del administrador de contraseñas y detiene la adopción de llaves de acceso.

Si la misma cuenta abarca varios dominios, el usuario debe reconocer que los dominios pertenecen a la misma organización y proporcionar las mismas credenciales cuando acceda. En el peor de los casos, el usuario crea una cuenta duplicada o divulga la contraseña a un sitio web de phishing.

Aprende a usar estándares y soluciones de arquitectura (como metadatos, elementos iframe de origen cruzado, federación de identidades y consolidación de subdominios) para resolver la fragmentación de identidades en varios dominios y ofrecer un recorrido del usuario fluido.

Alternativas comunes

Las organizaciones utilizan varias técnicas establecidas para mantener un recorrido entre dominios. Si bien estos métodos son comunes, enfrentan obstáculos estructurales a medida que los navegadores aplican límites de privacidad y estándares de seguridad más estrictos.

Solicitudes de recuperación de CORS

Cuando los dominios operan de forma independiente, los frontends suelen depender de solicitudes fetch() de origen cruzado dirigidas a una API de autenticación centralizada, que se puede permitir de forma segura con el uso compartido de recursos entre dominios (CORS). Dado que los navegadores suelen bloquear o restringir las cookies de sitios cruzados, es posible que los desarrolladores diseñen explícitamente estas APIs para que muestren tokens de autenticación, como tokens web JSON (JWT) dentro de cargas útiles JSON, en lugar de depender de los encabezados Set-Cookie.

Uso compartido de la base de datos de la cuenta

Para unificar la identidad en el backend sin integraciones complejas en el frontend, puedes centralizar su almacén de datos del usuario. Aunque varios dominios se autentican en la misma base de datos, sus experiencias de acceso desde el frontend siguen siendo independientes. Esto obliga a los usuarios a recordar en qué dominios usaron la misma credencial, lo que genera una mala experiencia del usuario.

Problemas con accesos no vinculados

Si bien las soluciones técnicas alternativas pueden lograr una funcionalidad básica, no ofrecen un recorrido fluido. Los flujos de acceso desconectados introducen puntos de fricción que comprometen la usabilidad y la seguridad.

Fragmentación del administrador de contraseñas

El punto de mayor fricción es la interrupción de los administradores de contraseñas. Los administradores de contraseñas vinculan las credenciales almacenadas al origen específico en el que se registran. Esto evita que el navegador ofrezca la función de autocompletar en diferentes dominios, incluso cuando pertenecen a la misma organización.

Cuando un usuario pasa de un dominio con credenciales guardadas a un dominio nuevo en tu organización, el administrador de contraseñas no reconoce la relación y no activa el mensaje de autocompletar. Esto genera fricción en la entrada manual. Los usuarios deben buscar sus credenciales, restablecer su contraseña o crear una cuenta duplicada.

Dado que el administrador de contraseñas no es confiable en estas propiedades, es posible que los usuarios abandonen las herramientas para estos sitios. En cambio, suelen crear contraseñas débiles y fáciles de recordar para reutilizarlas en otros lugares, lo que degrada la seguridad general de tu organización.

Puerta de enlace de phishing

Esta interrupción funciona como una puerta de enlace de phishing. La negativa del administrador de contraseñas a autocompletar un dominio no reconocido es un mecanismo de defensa principal. Al requerir que los usuarios ingresen manualmente las credenciales en diferentes URLs, sin intención, los capacitas para que sean víctimas de ataques de phishing.

Publicación simultánea garantizada de la llave de acceso

La fricción aumenta cuando usas llaves de acceso. La arquitectura de seguridad principal de WebAuthn vincula criptográficamente las llaves de acceso de forma estricta a un ID de grupo de confianza (ID de RP) especificado.

Esto crea una "trampa de ID de RP". Una llave de acceso registrada en brand.example no se puede usar en service-app.example porque el navegador deniega el acceso entre dominios. Para evitar que se les solicite a los usuarios que registren llaves de acceso distintas para cada sitio, debes consolidar estas propiedades en un solo ID de RP.

Enfoques recomendados

Para establecer la continuidad de la identidad, debes dejar de usar las integraciones de acceso ad hoc y adoptar estándares arquitectónicos reconocidos:

• Usa archivos de configuración de metadatos: Aloja archivos de metadatos, como los de Digital Asset Links y Related Origin Requests, para establecer una cadena de confianza criptográfica. Esto permite compartir sin problemas credenciales y llaves de acceso en diferentes dominios y apps para dispositivos móviles. Este enfoque es una solución silenciosa y de bajo costo para la fragmentación de la identidad que no requiere una reestructuración compleja de la infraestructura web existente.
• Usa iframes de origen cruzado: Incorpora un origen de autenticación centralizado como un iframe dentro de una parte que confía para conectar las credenciales guardadas y las llaves de acceso en diferentes sitios. Este enfoque utiliza la Política de permisos y las cookies particionadas para habilitar una experiencia de acceso fluida y contextual, a la vez que mantiene límites de seguridad estrictos a través de la CSP y la mensajería entre documentos.
• Sigue la federación de identidades estándar: Adopta protocolos estándar de la industria, como OpenID Connect, para centralizar la autenticación en un dominio de proveedor de identidad (IdP) dedicado. Esto formaliza el recorrido de acceso a través de redireccionamientos seguros, lo que reemplaza las integraciones frágiles por una solución propia confiable y escalable.
• Consolida los subdominios: Realiza la transición a subdominios bajo una raíz común. Esto permite compartir sesiones sin problemas a través de cookies comodín y continuidad de llaves de acceso en todo el dominio registrable. Muchos administradores de contraseñas pueden reconocer el dominio raíz compartido y sugerir automáticamente las credenciales guardadas en los subdominios relacionados.

Usa archivos de configuración de metadatos

Uno de los principales desafíos de la identidad entre dominios es la fragmentación de las credenciales guardadas. Los administradores de contraseñas tratan a los diferentes dominios y aplicaciones como entidades completamente aisladas, lo que les impide autocompletar las credenciales guardadas en una propiedad en otra.

Para abordar la fragmentación, puedes configurar el comportamiento de los administradores de contraseñas en lugar de alterar la estructura de tu sitio web. Al alojar archivos de configuración de metadatos específicos, las organizaciones pueden afirmar de forma criptográfica que los dominios y las aplicaciones dispares pertenecen a la misma organización. Esto permite que los sistemas operativos, los navegadores y los administradores de contraseñas reconozcan esta relación y conecten automáticamente el contexto de identidad, compartiendo contraseñas y llaves de acceso en tus propiedades. Este enfoque también es necesario para compartir contraseñas y llaves de acceso basadas en la Web con aplicaciones para dispositivos móviles, incluso si tus dominios web están consolidados.

Usa dos archivos de configuración diferentes para asegurarte de abarcar diferentes plataformas y ecosistemas:

• Administrador de contraseñas de Google en Android y Chrome: Aloja un archivo JSON de Vínculos de recursos digitales (DAL) en /.well-known/assetlinks.json para establecer una relación de confianza verificable entre los sitios web y las apps asociadas de una organización. Esta confianza habilita los vínculos directos en las apps y el uso compartido de credenciales sin problemas, en el que las contraseñas guardadas en la Web se autocompletan automáticamente en los sitios web asociados (aunque el uso compartido de llaves de acceso en varios dominios web aún requiere solicitudes de origen relacionado). Obtén más información en la guía sobre el uso compartido de credenciales sin problemas.

• Contraseñas de Apple en iOS y Safari: Aloja un archivo de Asociación de sitios de apps de Apple (AASA) en /.well-known/apple-app-site-association para establecer la cadena de confianza criptográfica necesaria para conectar los estados de Contraseñas de Apple en las apps para iOS y Safari. Para admitir ecosistemas de terceros, puedes declarar estos dominios asociados de forma centralizada con un repositorio de colaboración abierta. De esta manera, se garantiza que las herramientas independientes (como 1Password, que ingiere explícitamente este repositorio) también reconozcan el contexto de identidad compartido. Para obtener más información sobre la Asociación de sitios de aplicaciones de Apple, consulta Cómo admitir dominios asociados.

Para habilitar las llaves de acceso en diferentes dominios web y abordar el obstáculo de las llaves de acceso, los desarrolladores pueden alojar un archivo de Related Origin Requests (ROR) en /.well-known/webauthn. ROR declara explícitamente los dominios autorizados que tienen permiso para compartir de forma segura el mismo ID de RP de llave de acceso. Para obtener más información sobre las solicitudes de origen relacionadas, consulta Permite la reutilización de llaves de acceso en tus sitios con las solicitudes de origen relacionadas.

• Ventajas:
  • Corrección en segundo plano para los usuarios finales: Funciona completamente en segundo plano, lo que resuelve automáticamente la fragmentación del autocompletar y establece la continuidad de la llave de acceso a nivel del SO o del navegador sin cambios visibles en la UX.
  • Implementación simple: Esta es una solución de bajo costo que solo requiere el alojamiento de archivos JSON estáticos. No requiere una reestructuración del backend ni una lógica compleja de intercambio de tokens.
  • Conserva la infraestructura existente: Puedes mejorar significativamente el recorrido en varios dominios sin cambiar tu marca ni consolidar tus dominios.
• Desventajas:
  • Restricciones de la plataforma: Las plataformas suelen aplicar límites estrictos en el ROR. Por ejemplo, Chrome restringe un solo ID de RP a un máximo de 5 etiquetas de eTLD+1 asociadas. Para ilustrarlo, example.co.uk y example.de comparten la misma etiqueta de eTLD+1 example; sin embargo, example-rewards.com usa una etiqueta example-rewards separada. Si administras una cartera de dominios extensa o variada, es posible que estos límites sean insuficientes.
  • Mayor latencia operativa: La resolución de archivos de metadatos requiere un viaje de ida y vuelta adicional a la red, lo que agrega latencia cuando el navegador procesa la autenticación.

Usa iframes de origen cruzado

Si no puedes usar el enfoque de archivos de configuración de metadatos debido a los límites de dominio de ROR, los elementos iframe de origen cruzado ofrecen una ruta sólida y compatible con los estándares para resolver los desafíos de acceso entre dominios.

Si incorporas un origen de autenticación centralizado (por ejemplo, auth.brand.example) como un iframe dentro de una entidad que confía (por ejemplo, brand.example), puedes interactuar con los campos de formulario habituales y las APIs modernas. En el caso de las contraseñas, el administrador de credenciales del navegador asocia las acciones de autocompletar con el origen del iframe (auth.example). Esto permite que los usuarios accedan a sus credenciales centralizadas sin problemas en diferentes sitios.

En el caso de las llaves de acceso, la ventana principal debe otorgar acceso al iframe con el marco de trabajo de la Política de permisos, lo que permite que el iframe invoque WebAuthn para autenticarse en el ID de RP de su propio origen. En ambos flujos, la CSP (Política de Seguridad del Contenido) es útil para proteger a los usuarios de ataques como el clickjacking y las secuencias de comandos entre sitios. Una vez que la autenticación se realiza correctamente, se establece la sesión con una cookie particionada y el token se transmite de forma segura a la ventana principal con postMessage().

• Ventajas:
  • Credenciales centralizadas: Evitan la fragmentación de credenciales. Un origen único y centralizado administra tanto las contraseñas guardadas como un ID de RP de llave de acceso unificado, lo que permite que los distintos dominios compartan estas credenciales sin necesidad de consolidar dominios.
  • Autenticación contextual: Todo el flujo de acceso, ya sea que se autocomplete una contraseña o se realice la verificación con una llave de acceso, se produce sin problemas en el contexto de la página principal, lo que evita redireccionamientos federados disruptivos.
  • Resistencia a las protecciones contra el seguimiento: Este enfoque funciona correctamente incluso con protecciones estrictas contra el seguimiento entre sitios que usan cookies particionadas.
• Desventajas:
  • Restricciones de implementación: Esta arquitectura exige ingeniería especializada. Requiere una CSP estricta (frame-ancestors) para restringir la incorporación a dominios principales de confianza y evitar el clickjacking, la configuración de políticas de permisos HTTP para habilitar la API de WebAuthn y la mensajería entre documentos segura y validada (postMessage()) para mitigar los ataques de suplantación de origen y CSRF. Obtén información sobre las prácticas recomendadas en Llaves de acceso dentro de elementos iframe.

Sigue la federación de identidades estándar

Adoptar la federación de identidades estándar, como OpenID Connect, es un enfoque sólido y sostenible para mantener tu sistema de cuentas. Este enfoque formaliza el flujo de trabajo de autenticación consolidándolo en un solo dominio de proveedor de identidad (IdP) dedicado, como auth.brand.example. Con un protocolo establecido, las aplicaciones redireccionan a los usuarios a este centro central para la autenticación antes de recibir de forma segura una transferencia de tokens para completar el acceso en el dominio de destino. Si bien a menudo se asocia con los accesos de terceros (como Acceder con Google), la federación estándar es completamente válida y se usa ampliamente como una solución propia para reemplazar las soluciones alternativas frágiles.

• Ventajas:
  • Lenguaje de ingeniería común: Los desarrolladores no necesitan aprender ni mantener un protocolo específico creado de forma personalizada, sino que pueden confiar en el conocimiento establecido de la industria y en bibliotecas integrales. También hay soluciones empaquetadas.
  • Confiabilidad probada en batalla: Los protocolos estándar son seguros, están comprobados y son mucho menos frágiles que las implementaciones ad hoc.
  • Fácil expansión: Si la organización necesita federarse con un nuevo servicio de terceros o integrar una adquisición más adelante, la infraestructura de identidad ya está equipada para proporcionar credenciales.
  • UX coherente: Los usuarios reconocen la página centralizada del IdP como la fuente autorizada de la marca, lo que aclara exactamente cuándo y dónde se requieren las credenciales.
• Desventajas:
  • Sobrecarga de integración alta: Desarrollar un IdP centralizado o migrar a uno introduce una sobrecarga de integración alta y requiere experiencia especializada en seguridad. Las organizaciones deben invertir en la refactorización segura de todas las aplicaciones conectadas para admitir patrones seguros basados en redireccionamientos.
  • Redireccionamientos disruptivos: El flujo de autenticación requiere que se redireccione a los usuarios desde el sitio de origen a una página centralizada del proveedor de identidad, lo que impide una experiencia de acceso sin inconvenientes y en contexto.

Consolida subdominios

Otro enfoque estructural es unificar todos los dominios trasladando las propiedades digitales dispares a un dominio raíz común registrable (el eTLD+1). Esto implica la transición de dominios independientes, como brand.example y service-app.example, a subdominios, como www.brand.example y service.brand.example.

• Ventajas:
  • Administración unificada de credenciales: Los administradores de contraseñas pueden reconocer el dominio raíz y tratar todos los subdominios como una sola entrada, lo que elimina las indicaciones duplicadas y la entrada manual de contraseñas.
  • Continuidad de la llave de acceso: Los desarrolladores pueden definir de forma nativa el alcance de un ID de RP de llave de acceso para el dominio registrable, lo que extiende instantáneamente la compatibilidad con llaves de acceso a todos los subdominios asociados. En este caso, un ID de RP de brand.example funcionará en www.brand.example y service.brand.example.
  • Compartir sesiones sin esfuerzo: La consolidación de la estructura de dominios permite compartir una sola sesión con cookies comodín (por ejemplo, definir el alcance de una cookie en Domain=brand.example).
• Desventajas:
  • Restricciones de desarrollo de la marca y migración: Este enfoque puede imponer posibles límites de desarrollo de la marca si tu organización exige dominios de nivel superior distintos. La migración es compleja y requiere una administración cuidadosa de los redireccionamientos HTTP y una corrección exhaustiva de las configuraciones heredadas de varios orígenes.

Conclusión

Para lograr la continuidad de la identidad, debes realizar la transición de las integraciones de acceso ad hoc a los estándares de autenticación establecidos. Si evalúas las restricciones comerciales en función de estas prácticas establecidas (como la federación, la consolidación de dominios, los iframes o los metadatos), puedes eliminar la fricción en la UX y mejorar la autenticación en todo tu ecosistema.

Para obtener más información sobre temas relacionados, sigue nuestro blog y explora más recursos en el portal de identidad de Chrome.