Orígenes Relacionados de WebAuthn: Guía para Passkeys entre Dominios

Las passkeys son el nuevo estándar para una autenticación segura y fácil de usar. Basadas en los estándares FIDO/WebAuthn, aprovechan la criptografía de clave pública para ofrecer una resistencia inherente al phishing y al credential stuffing, mejorando drásticamente la postura de seguridad mientras simplifican la experiencia de inicio de sesión para los usuarios. Para las organizaciones, esto se traduce en beneficios comerciales tangibles: reducción de costos operativos por restablecimiento de contraseñas y OTP por SMS, mitigación de riesgos financieros por fraudes de apropiación de cuentas y aumento de ingresos a través de mayores tasas de conversión.

Sin embargo, una de las mayores fortalezas de seguridad de WebAuthn —su naturaleza estricta y vinculada al origen— crea un desafío significativo en el mundo real para las marcas globales y las empresas con diversas presencias digitales. Por diseño, una passkey creada para un dominio web específico está criptográficamente bloqueada a ese dominio, un principio fundamental que previene los ataques de phishing. Si bien esta es una potente característica de seguridad, conduce a una experiencia de usuario fragmentada y confusa cuando una sola marca opera en múltiples dominios.

Un ejemplo destacado de este desafío es el cambio de marca de Twitter a X. Un usuario que creó una passkey en twitter.com la encontraría inutilizable en x.com, lo que obligó a la empresa a implementar redirecciones engorrosas o a exigir a los usuarios que se volvieran a registrar, creando una fricción que obstaculiza directamente la adopción. Este no es un problema aislado. Grandes empresas como Amazon operan en numerosos dominios de nivel superior de código de país (ccTLD) como amazon.com, amazon.de y amazon.co.uk, todos compartiendo un sistema de cuentas de usuario común. En un mundo anterior a las passkeys, los gestores de contraseñas manejaban esta complejidad con destreza, pero el comportamiento predeterminado de WebAuthn requeriría una passkey separada para cada dominio, frustrando a los usuarios y socavando la promesa de un inicio de sesión sin interrupciones.

Para resolver este bloqueador crítico de adopción, el W3C ha introducido una nueva característica en el estándar WebAuthn: Solicitudes de Orígenes Relacionados (ROR, por sus siglas en inglés). Este poderoso mecanismo proporciona una forma estandarizada y segura para que un conjunto de dominios de confianza compartan una única passkey, creando una experiencia de autenticación unificada y fluida en todo el ecosistema digital de una marca. Este análisis profundo explora los fundamentos técnicos de ROR, proporciona una guía práctica para su implementación y analiza sus implicaciones estratégicas para la arquitectura de autenticación moderna.

La introducción de ROR marca una maduración significativa del estándar WebAuthn. Las especificaciones iniciales priorizaron el establecimiento de principios criptográficos y de seguridad fundamentales, siendo la vinculación estricta de una credencial a un ID de Relying Party (rpID) una piedra angular de su diseño anti-phishing. A medida que los despliegues empresariales a gran escala por parte de empresas como Amazon y Google se hicieron realidad, la fricción práctica causada por esta rigidez se hizo evidente. Esta fricción es un impedimento directo para lograr una alta adopción por parte de los usuarios, que es la medida definitiva del éxito de cualquier proyecto de passkeys. El desarrollo de ROR es una respuesta directa a esta retroalimentación empresarial, demostrando una evolución pragmática del estándar. Reconoce que para que un protocolo de seguridad alcance un éxito generalizado, su usabilidad debe escalar para adaptarse a las complejas realidades comerciales y estrategias de marca de las organizaciones que lo implementan.

Esta guía completa responde a cinco preguntas críticas para implementar las Solicitudes de Orígenes Relacionados de WebAuthn:

1. ¿Por qué las passkeys fallan en múltiples dominios? Entendiendo el modelo de seguridad de WebAuthn vinculado al origen y sus puntos de fricción en el mundo real.
2. ¿Cómo funcionan técnicamente las Solicitudes de Orígenes Relacionados? Un análisis profundo del flujo de validación del navegador y el mecanismo de URI .well-known.
3. ¿Qué se requiere para implementar ROR? Configuración paso a paso del lado del servidor y del cliente con ejemplos de código prácticos.
4. ¿Cuándo deberías elegir ROR en lugar del inicio de sesión federado? Un marco de decisión estratégico que compara ROR con los enfoques OIDC/SAML.
5. ¿Cómo manejar la compatibilidad de navegadores y las consideraciones de seguridad? Matriz de soporte actual y mejores prácticas de seguridad.

Para más detalles técnicos, consulta el Explicador oficial de Solicitudes de Orígenes Relacionados de WebAuthn.

Para apreciar plenamente la elegancia de la solución de las Solicitudes de Orígenes Relacionados, es esencial entender primero los conceptos técnicos subyacentes que hacen necesaria su existencia: la Política del Mismo Origen de la web y las reglas de alcance del ID de Relying Party (rpID) de WebAuthn. Estos mecanismos son fundamentales para la seguridad web, pero crean la misma fricción que ROR está diseñado para aliviar.

Un "origen" web es un concepto de seguridad crítico definido por la combinación única del protocolo (p. ej., https), el dominio (p. ej., app.example.com) y el puerto (p. ej., 443) desde el cual se sirve el contenido. La Política del Mismo Origen es un mecanismo de seguridad aplicado por los navegadores que restringe cómo un script cargado desde un origen puede interactuar con un recurso de otro. Es un elemento importante de la seguridad web, aislando eficazmente documentos potencialmente maliciosos e impidiendo que un sitio web fraudulento, por ejemplo, lea datos sensibles de la sesión de correo web autenticada de un usuario en otra pestaña.

En el ecosistema WebAuthn, el "Relying Party" (RP) es el sitio web o la aplicación con la que un usuario intenta autenticarse. Cada passkey está criptográficamente vinculada a un ID de Relying Party (rpID) en el momento de su creación. El rpID es un nombre de dominio que define el alcance y el límite de esa credencial.

Por defecto, el rpID es el dominio efectivo del origen donde se está creando la passkey. Las reglas de alcance de WebAuthn permiten que un origen establezca un rpID que sea igual a su propio dominio o a un sufijo de dominio registrable. Por ejemplo, un script que se ejecuta en https://www.accounts.example.co.uk puede crear una passkey con un rpID de:

• www.accounts.example.co.uk (el dominio completo)
• accounts.example.co.uk
• example.co.uk

Esta flexibilidad permite que una passkey creada en un subdominio se use en otros subdominios del mismo dominio principal, lo cual es un patrón común y necesario. Sin embargo, las reglas prohíben estrictamente establecer un rpID que no sea un sufijo. El mismo script en www.accounts.example.co.uk no podría crear una passkey con un rpID de example.com, porque .com es un dominio de nivel superior diferente.

Esta vinculación estricta tiene un propósito importante: separar las credenciales por alcance de dominio. Una passkey creada para mybank.com no se puede usar en phishing-site.com porque el sitio malicioso no puede reclamar el rpID legítimo de mybank.com. El navegador ni siquiera presentará la passkey como una opción.

Sin embargo, el rpID en sí mismo no es el principal control anti-phishing. La protección anti-phishing de WebAuthn en realidad proviene de la verificación del origen en el objeto clientDataJSON. Durante cada ceremonia de WebAuthn, el navegador crea un objeto JSON que contiene contexto crítico, incluido el origen exacto que inició la solicitud. Este objeto completo es luego firmado criptográficamente por la clave privada del autenticador. El servidor (Relying Party) DEBE verificar esta firma y, de manera crucial, validar que el campo de origen en el clientDataJSON firmado coincida con un valor esperado y de confianza. Esta verificación de origen es lo que previene los ataques de phishing.

Con las Solicitudes de Orígenes Relacionados, el alcance del rpID se relaja —permitiendo que bar.com reclame legítimamente el rpID de foo.com después de que el navegador valide el archivo .well-known/webauthn— pero el requisito de verificación de origen permanece sin cambios. El clientDataJSON seguirá informando verazmente el origen como bar.com. El servidor en foo.com recibe estos datos firmados, los verifica y ve que la solicitud provino de bar.com. El servidor debe entonces comprobar que bar.com es un origen relacionado esperado antes de aceptar la autenticación. Esto demuestra un enfoque de múltiples capas que permite una mayor flexibilidad sin sacrificar el principio fundamental de la verificación de origen.

El mecanismo de Solicitudes de Orígenes Relacionados introduce una forma elegante y estandarizada para que los dominios declaren públicamente una relación de confianza con el propósito de compartir passkeys. Aprovecha un patrón web bien establecido —la URI /.well-known/— para crear una "lista de permitidos" verificable y legible por máquina que los navegadores pueden consultar.

El concepto central es sencillo: un dominio que sirve como el rpID principal y canónico para un conjunto de sitios relacionados puede alojar un archivo JSON especial en una URL estandarizada y "bien conocida": https://{rpID}/.well-known/webauthn. Este archivo actúa como un manifiesto público, listando explícitamente todos los demás orígenes que están oficialmente autorizados para crear y usar passkeys bajo ese rpID principal.

El flujo de validación del navegador se activa cada vez que encuentra una discrepancia entre el origen actual y el rpID solicitado:

1. Un usuario en un sitio "relacionado", como https://example.co.uk, inicia una operación de passkey (creación o autenticación) donde el código del lado del cliente especifica un dominio diferente como rpID, por ejemplo, example.com.
2. El navegador detecta esta discrepancia. Bajo las reglas antiguas, esto resultaría inmediatamente en un SecurityError.
3. Con el soporte de ROR, el navegador, antes de fallar, realiza una solicitud HTTPS GET segura a la URL bien conocida del rpID reclamado: https://example.com/.well-known/webauthn. Esta solicitud se realiza sin credenciales de usuario (como cookies) y sin una cabecera de referente para proteger la privacidad del usuario y evitar el rastreo.
4. El navegador recibe la respuesta JSON del servidor. Analiza el archivo y comprueba si el origen actual (https://example.co.uk) está presente en el array de origins dentro del objeto JSON.
5. Si se encuentra el origen en la lista de permitidos, la operación de WebAuthn puede continuar usando example.com como el rpID válido. Si no se encuentra el origen, o si el archivo falta o está mal formado, la operación falla como lo habría hecho anteriormente.

La elección de usar una URI /.well-known/ es deliberada y alinea ROR con los estándares web establecidos para el descubrimiento de servicios y la validación del control de dominios. Esta ruta de URI, definida por RFC 8615, ya es utilizada por numerosos protocolos críticos, incluido el acme-challenge para la emisión de certificados SSL de Let's Encrypt y assetlinks.json para vincular sitios web con aplicaciones de Android. Al adoptar esta convención, el W3C aprovecha un patrón que implica inherentemente la propiedad del dominio. Para colocar un archivo en esta ruta específica y estandarizada, uno debe tener control administrativo sobre el servidor web de ese dominio. Esto proporciona una prueba de control simple pero efectiva, haciendo que la declaración de confianza sea verificable. Cuando el propietario de example.com sirve un archivo que lista a example.co.uk como un origen relacionado, es una afirmación verificable. Este enfoque nativo de la web es mucho más simple y robusto que las alternativas que se consideraron y rechazaron durante el proceso de estandarización, como el uso de claves criptográficas para firmar autorizaciones (RP Keys) o identificadores aleatorios no basados en dominios (RP UUIDs). ROR basa la relación de confianza en el modelo de control de dominio existente y bien entendido de la web.

Implementar las Solicitudes de Orígenes Relacionados requiere cambios coordinados tanto en el lado del servidor, para autorizar los orígenes, como en el lado del cliente, para invocar el rpID compartido. Esta sección proporciona los detalles prácticos de código y configuración necesarios para habilitar una experiencia de passkey unificada en todos tus dominios.

El servidor que aloja el rpID principal es responsable de publicar la lista de permitidos de orígenes relacionados.

El archivo de autorización debe colocarse en la ruta exacta /.well-known/webauthn relativa a la raíz del dominio del rpID principal. Es fundamental que este archivo se sirva bajo las siguientes condiciones:

• Protocolo: Debe servirse sobre HTTPS.
• Content-Type: La cabecera de respuesta HTTP Content-Type debe establecerse en application/json.
• Extensión del Archivo: La URL no debe incluir una extensión .json. La ruta correcta es /webauthn, no /webauthn.json.

El archivo debe contener un único objeto JSON con una clave, origins, cuyo valor es un array de strings. Cada string en el array es el origen completo (protocolo, dominio y puerto opcional) que se está autorizando.

{
    "origins": ["https://example.co.uk", "https://example.de", "https://example.fr"]
}

Ejemplo: Para un rpID de example.com, el archivo debe servirse en https://example.com/.well-known/webauthn (nota: sin extensión .json).

Una vez que el servidor está configurado con el archivo .well-known/webauthn, todos los dominios relacionados deben usar consistentemente el mismo rpID compartido en sus llamadas a la API de WebAuthn. Esta coordinación es crítica para que ROR funcione correctamente.

Requisitos clave de coordinación:

1. Responsabilidad del backend: El servidor genera el desafío criptográfico y especifica el rpID compartido tanto en las solicitudes de creación de credenciales como en las de autenticación.
2. Responsabilidad del frontend: Todas las aplicaciones cliente (example.com, example.co.uk, example.de) deben pasar el mismo rpID compartido a la API navigator.credentials del navegador.
3. Gestión de la configuración: El rpID compartido debe tratarse como un valor de configuración global crítico aplicado de manera consistente en todos los sitios relacionados.

Una configuración incorrecta incluso en un solo sitio —donde se utiliza por defecto su propio origen como rpID en lugar del valor compartido— romperá la experiencia de passkey unificada para los usuarios en ese dominio.

Importante: El servidor DEBE verificar el campo origin en el clientDataJSON para cada solicitud, asegurándose de que coincida con uno de los orígenes relacionados autorizados. Esta verificación de origen es el principal mecanismo de protección contra el phishing.

Las Solicitudes de Orígenes Relacionados (ROR) y los protocolos de identidad federada (OIDC/SAML) resuelven problemas diferentes. ROR no es un reemplazo para el Single Sign-On, es un complemento que aborda un caso de uso específico y acotado.

ROR es apropiado para una única aplicación lógica distribuida en múltiples dominios relacionados que comparten la misma base de datos de usuarios:

• Una única marca que opera múltiples TLD de código de país (p. ej., amazon.com, amazon.de, amazon.co.uk).
• Todos los dominios comparten el mismo sistema de autenticación de backend y base de datos de usuarios.
• Quieres evitar flujos basados en redirecciones y mantener la autenticación contextual a cada dominio.
• Tus dominios se encuentran dentro del límite de 5 etiquetas.
• Los usuarios deben experimentar todos los dominios como un único servicio cohesivo.

Lo que ROR proporciona: La misma passkey funciona en todos los dominios relacionados, eliminando la necesidad de que los usuarios creen passkeys separadas para cada sitio regional.

Usa protocolos de identidad federada para un verdadero Single Sign-On entre aplicaciones distintas:

• Múltiples servicios con bases de datos de usuarios o sistemas de identidad separados.
• Escenarios empresariales donde los usuarios necesitan acceso a muchas aplicaciones diferentes (Salesforce, Office 365, herramientas internas).
• Integración de aplicaciones de terceros.
• Necesitas control de acceso centralizado, registros de auditoría y gobernanza de identidades.
• Superas el límite de 5 etiquetas para orígenes relacionados.

Lo que OIDC/SAML proporciona: Autenticación centralizada donde los usuarios inician sesión una vez en un Proveedor de Identidad (IdP) y obtienen acceso a múltiples Proveedores de Servicios (SP) a través de tokens seguros.

Importante: Las passkeys se pueden usar con ambos enfoques. Puedes implementar passkeys en un IdP centralizado para SSO federado, o usar ROR para una aplicación única multidominio. Elige en función de tu arquitectura, no de tu método de autenticación.

Aunque ROR es una solución técnica potente, su implementación debe ser una decisión estratégica deliberada. Los arquitectos y los gerentes de producto deben sopesar sus beneficios frente a patrones alternativos y comprender sus limitaciones para construir un sistema de autenticación robusto y preparado para el futuro.

Una restricción clave de ROR es el "límite de etiquetas". Una "etiqueta" en este contexto se refiere al dominio de nivel superior efectivo más un nivel (eTLD+1), que es la parte registrable de un nombre de dominio. Por ejemplo:

• shopping.com, shopping.co.uk, y shopping.ca comparten la única etiqueta "shopping".
• myshoppingrewards.com introduce una nueva etiqueta distinta: "myshoppingrewards".
• travel.shopping.com todavía cae bajo la etiqueta "shopping".

La especificación WebAuthn Nivel 3 requiere que las implementaciones de los navegadores soporten un mínimo de cinco etiquetas únicas en la lista de origins. A partir de 2025, ningún navegador conocido soporta más de este mínimo de cinco etiquetas. Por lo tanto, las organizaciones deben diseñar sus implementaciones de ROR con este límite estricto en mente: tratar cinco como el máximo efectivo.

Este límite es un mecanismo deliberado anti-abuso diseñado para prevenir el uso indebido. Impide que entidades como los proveedores de hosting compartido (p. ej., wordpress.com) creen una passkey universal que podría funcionar en miles de subdominios de clientes no relacionados, lo que socavaría el modelo de seguridad.

Para la mayoría de las organizaciones, incluso las grandes marcas multinacionales, este límite de cinco etiquetas es suficiente. Por ejemplo, los diversos TLD de código de país de Amazon (amazon.com, amazon.de, amazon.co.uk, etc.) comparten la etiqueta "amazon", dejando cuatro espacios de etiqueta adicionales disponibles para otras marcas en su cartera como "audible" o "zappos".

La complejidad de implementar ROR depende en gran medida de si se está introduciendo en un sistema nuevo o adaptando a uno existente.

• Despliegues Nuevos (Greenfield): Para proyectos nuevos, la estrategia es sencilla. Se debe elegir un único dominio canónico como el rpID compartido desde el principio (p. ej., el dominio principal .com). Este rpID debe usarse consistentemente en la configuración de todos los sitios web y aplicaciones relacionados desde el primer día.
• Despliegues Existentes: Adaptar ROR a un sistema que ya tiene passkeys desplegadas con diferentes rpIDs en sus dominios es significativamente más complejo. Una migración directa no es posible, ya que las passkeys existentes están permanentemente vinculadas a sus rpIDs originales. El enfoque recomendado en este escenario es implementar un flujo de inicio de sesión "primero el identificador". Primero se le pide al usuario que ingrese su nombre de usuario o correo electrónico. El backend luego realiza una búsqueda para determinar con qué rpID está asociada su passkey existente. Finalmente, se redirige al usuario al origen correcto correspondiente a ese rpID para completar la ceremonia de autenticación. Después de un inicio de sesión exitoso, se le puede redirigir de nuevo a su sitio original. Esta es una empresa arquitectónica considerable que requiere una planificación e implementación cuidadosas.

Entender cómo las empresas establecidas implementan las Solicitudes de Orígenes Relacionados proporciona información valiosa para tu propia estrategia de despliegue. A continuación se presentan ejemplos basados en implementaciones reales (a fecha de octubre de 2025):

Microsoft utiliza ROR para su infraestructura de autenticación. La configuración real en login.microsoftonline.com incluye:

// https://login.microsoftonline.com/.well-known/webauthn
{
    "origins": ["https://login.microsoftonline.com", "https://login.live.com"]
}

Este enfoque conservador permite compartir passkeys entre los portales de inicio de sesión empresariales y de consumo de Microsoft, manteniendo al mismo tiempo un perímetro de seguridad enfocado.

Shopify implementa ROR para unificar la autenticación en dominios seleccionados:

// https://shopify.com/.well-known/webauthn
{
    "origins": ["https://shopify.com", "https://shop.app"]
}

Esta configuración permite a Shopify conectar su plataforma principal con su aplicación Shop, demostrando un enfoque centrado en los orígenes relacionados.

Amazon tiene un archivo bastante grande:

// https://amazon.com/.well-known/webauthn
{
    "origins": [
        "https://www.amazon.com",
        "https://www.amazon.com.br",
        "https://www.amazon.com.mx",
        "https://www.amazon.ca",
        "https://www.amazon.co.uk",
        "https://www.amazon.de",
        "https://www.amazon.it",
        "https://www.amazon.es",
        "https://www.amazon.nl",
        "https://www.amazon.se",
        "https://www.amazon.sa",
        "https://www.amazon.pl",
        "https://www.amazon.com.tr",
        "https://www.amazon.fr",
        "https://www.amazon.com.au",
        "https://www.amazon.sg",
        "https://www.amazon.ae",
        "https://www.amazon.eg",
        "https://www.amazon.co.za",
        "https://www.amazon.in",
        "https://brandregistry.amazon.com",
        "https://sellercentral.amazon.com",
        "https://sellercentral.amazon.com.br",
        "https://sellercentral.amazon.com.mx",
        "https://sellercentral.amazon.ca",
        "https://sellercentral.amazon.co.uk",
        "https://sellercentral.amazon.de",
        "https://sellercentral.amazon.it",
        "https://sellercentral.amazon.es",
        "https://sellercentral.amazon.nl",
        "https://sellercentral.amazon.se",
        "https://sellercentral.amazon.sa",
        "https://sellercentral.amazon.pl",
        "https://sellercentral.amazon.com.tr",
        "https://sellercentral.amazon.fr",
        "https://sellercentral.amazon.com.au",
        "https://sellercentral.amazon.sg",
        "https://sellercentral.amazon.ae",
        "https://sellercentral.amazon.eg",
        "https://sellercentral.amazon.co.za",
        "https://sellercentral.amazon.in",
        "https://na.account.amazon.com",
        "https://vendorcentral.amazon.com",
        "https://vendorcentral.amazon.com.br",
        "https://vendorcentral.amazon.com.mx",
        "https://vendorcentral.amazon.ca",
        "https://vendorcentral.amazon.co.uk",
        "https://vendorcentral.amazon.de",
        "https://vendorcentral.amazon.it",
        "https://vendorcentral.amazon.es",
        "https://vendorcentral.amazon.nl",
        "https://vendorcentral.amazon.se",
        "https://vendorcentral.amazon.pl",
        "https://vendorcentral.amazon.com.tr",
        "https://vendorcentral.amazon.fr",
        "https://vendorcentral.amazon.com.au",
        "https://vendorcentral.amazon.co.za"
    ]
}

Este patrón permitiría a una marca proporcionar una autenticación de passkey unificada en todos los dominios regionales mientras utiliza el dominio principal .com como rpID.

Estos ejemplos del mundo real revelan varios patrones clave:

1. Dominio Principal como rpID: Todas las empresas utilizan su dominio .com principal como el rpID canónico.
2. Agrupación Lógica: Los orígenes se agrupan por función comercial en lugar de por arquitectura técnica.
3. Alcance Conservador: La mayoría de las implementaciones se mantienen muy por debajo del límite de 5 etiquetas, utilizando típicamente 3-4 orígenes.
4. Estrategia de Subdominios: Muchos utilizan subdominios del dominio principal para mantener la coherencia de la marca.

Como estándar web moderno, ROR ha sido diseñado con la seguridad como una consideración principal y está viendo una adopción activa en los principales navegadores.

Las Solicitudes de Orígenes Relacionados no comprometen las garantías anti-phishing fundamentales de WebAuthn. El mecanismo está cuidadosamente diseñado para mantener una postura de seguridad sólida:

• Verificación de Origen: Como se discutió, el navegador todavía incluye el verdadero origen de la solicitud en el clientDataJSON firmado. El servidor Relying Party DEBE verificar este origen para asegurarse de que la solicitud proviene de una fuente esperada, evitando que un origen relacionado comprometido se haga pasar por otro.
• Obtención Segura: La solicitud del navegador al archivo .well-known/webauthn se realiza a través de HTTPS. Además, la especificación exige que esta obtención se realice sin credenciales (p. ej., cookies) y sin una cabecera Referer. Esto evita que la solicitud se utilice para filtrar información del usuario o para fines de seguimiento entre sitios.
• Seguridad del Servidor: El archivo .well-known/webauthn se convierte en un activo de seguridad crítico. Un atacante que obtenga el control del servidor web que aloja el rpID principal podría modificar este archivo para añadir su propio dominio malicioso a la lista de permitidos. Por lo tanto, asegurar la infraestructura que sirve este archivo es de suma importancia.

Las Solicitudes de Orígenes Relacionados es una característica de la especificación WebAuthn Nivel 3. El soporte en navegadores comenzó a implementarse a finales de 2024:

Datos clave:

• Chrome y Edge: Añadieron soporte para ROR en la versión 128 (agosto de 2024).
• Safari: Añadió soporte para ROR en Safari 18, disponible en macOS 15 y iOS 18 (septiembre de 2024).
• Firefox: Actualmente sin soporte para ROR; detecta la característica e implementa flujos de fallback.

Para las aplicaciones que necesitan dar soporte a navegadores más antiguos o a Firefox, implementa una estrategia de fallback:

1. Detección de características: Comprueba el soporte de ROR usando PublicKeyCredential.getClientCapabilities().
2. Flujo de primero el identificador: Pide el nombre de usuario/correo electrónico, busca el rpID asociado al usuario y luego redirige al origen apropiado para la autenticación.
3. Degradación gradual: Permite a los usuarios crear passkeys separadas por dominio si ROR no está disponible.

Datos basados en las matrices de soporte actuales a fecha de octubre de 2025.

Implementar las Solicitudes de Orígenes Relacionados requiere una coordinación cuidadosa entre múltiples equipos técnicos y una profunda experiencia en los protocolos de WebAuthn. La plataforma de adopción de passkeys de Corbado elimina esta complejidad al proporcionar soluciones listas para empresas para implementaciones de passkeys multidominio.

Corbado maneja la complejidad técnica de las Solicitudes de Orígenes Relacionados a través de:

• Configuración Automatizada: Nuestra plataforma genera y aloja automáticamente los archivos .well-known/webauthn requeridos con las cabeceras de seguridad y el formato JSON adecuados.
• Panel de Control Multidominio: Interfaz de gestión centralizada para configurar orígenes relacionados en toda tu cartera de dominios.
• Herramientas de Validación: Pruebas y validación integradas para garantizar que tu configuración de ROR funcione correctamente en todos los navegadores y plataformas.

Más allá de la implementación técnica, Corbado proporciona el marco de seguridad que las empresas necesitan:

• Verificación de Origen: Validación automática de los orígenes de clientDataJSON para prevenir el abuso de dominios relacionados.
• Registro de Auditoría: Seguimiento completo del uso de passkeys en todos los dominios relacionados para el monitoreo de seguridad y cumplimiento.
• Respuesta a Incidentes: Alertas en tiempo real y respuestas automatizadas para intentos sospechosos de autenticación entre dominios.

Para organizaciones con implementaciones de passkeys existentes, Corbado ofrece:

• Herramientas de Migración de Legado: Análisis automatizado de las configuraciones de rpID existentes y recomendaciones de rutas de migración.
• Flujos de Primero el Identificador: Componentes de inicio de sesión pre-construidos que manejan escenarios complejos de múltiples rpID durante los períodos de transición.
• Integración de API: APIs RESTful y SDKs que se integran sin problemas con tu infraestructura de autenticación existente.

¿Listo para implementar las Solicitudes de Orígenes Relacionados en tu organización? El equipo de expertos de Corbado puede ayudarte a diseñar y desplegar una experiencia de passkey unificada en todo tu ecosistema digital. Contacta a nuestro equipo de soluciones para discutir tus requisitos específicos y plazos.

La promesa de las passkeys radica en su capacidad para ofrecer un futuro que es a la vez más seguro y notablemente más simple para los usuarios. Sin embargo, para que este futuro se convierta en una realidad a escala global, el estándar debe adaptarse a las complejidades arquitectónicas de las marcas digitales modernas. La fricción creada por las passkeys estrictamente vinculadas al dominio ha sido un importante obstáculo para la adopción por parte de organizaciones con presencias en línea multifacéticas.

Las Solicitudes de Orígenes Relacionados de WebAuthn proporcionan la solución estandarizada, segura y elegante a este problema. Al permitir que una única passkey funcione sin problemas en un conjunto de dominios relacionados de confianza, ROR elimina un punto importante de confusión y frustración para el usuario.

Esta guía abordó cinco preguntas críticas para implementar las Solicitudes de Orígenes Relacionados de WebAuthn:

1. ¿Por qué las passkeys fallan en múltiples dominios? El modelo de seguridad de WebAuthn vinculado al origen bloquea criptográficamente las passkeys a dominios específicos para prevenir el phishing, pero esto crea fricción cuando las marcas operan en múltiples dominios como diferentes TLD de país.
2. ¿Cómo funcionan técnicamente las Solicitudes de Orígenes Relacionados? ROR utiliza un archivo estandarizado .well-known/webauthn para crear una lista de permitidos verificable de dominios relacionados, permitiendo a los navegadores validar el uso de passkeys entre dominios a través de un proceso de obtención HTTPS seguro.
3. ¿Qué se requiere para implementar ROR? La implementación requiere la configuración del lado del servidor del archivo manifiesto .well-known/webauthn y la coordinación del lado del cliente para usar un rpID compartido de manera consistente en todos los orígenes relacionados.
4. ¿Cuándo deberías elegir ROR en lugar del inicio de sesión federado? Usa ROR para experiencias de marca unificadas en dominios relacionados con bases de datos de usuarios compartidas; usa OIDC/SAML para un verdadero SSO entre aplicaciones distintas o cuando se excede el límite de 5 etiquetas.
5. ¿Cómo manejar la compatibilidad de navegadores y las consideraciones de seguridad? ROR es compatible con los principales navegadores a partir de Chrome/Firefox 128+, Safari en macOS 15+, y iOS 18+, con estrategias de fallback disponibles para navegadores más antiguos a través de flujos de primero el identificador.

Para los equipos técnicos y los líderes de producto, los puntos esenciales son:

• ROR permite una experiencia de passkey unificada para una única aplicación lógica distribuida en múltiples dominios, como aquellos con diferentes TLD de código de país o marcas alternativas.
• La implementación requiere un esfuerzo coordinado: se debe publicar un archivo .well-known/webauthn del lado del servidor en el dominio del rpID principal, y todas las aplicaciones del lado del cliente deben configurarse para usar ese mismo rpID compartido.
• La decisión de usar ROR es estratégica. Es una excelente herramienta para sus casos de uso específicos, pero debe sopesarse frente a una arquitectura de inicio de sesión federado más tradicional (OIDC/SAML), especialmente en escenarios que involucran un verdadero Single Sign-On entre aplicaciones dispares.

Características como las Solicitudes de Orígenes Relacionados son vitales para el impulso continuo del movimiento sin contraseñas. Demuestran un compromiso por parte de los organismos de estandarización para abordar los desafíos de implementación del mundo real, asegurando que los beneficios de las passkeys —seguridad sin igual y una experiencia de usuario sin esfuerzo— sean accesibles incluso para las organizaciones más grandes y complejas. A medida que esta característica gane soporte universal en los navegadores, desempeñará un papel crucial en la eliminación de las barreras finales hacia una internet verdaderamente global y sin contraseñas.