Permite la reutilización de llaves de acceso en tus sitios con las solicitudes de origen relacionadas

Maud Nalpas

Las llaves de acceso están vinculadas a un sitio web específico y solo se pueden usar para acceder a ese sitio web.

Esto se especifica en el ID de la parte que confía (RP ID), que, para las llaves de acceso creadas para el dominio example.com, podría ser www.example.com o example.com.

Si bien los IDs de RP impiden que las llaves de acceso se usen como una sola credencial para la autenticación en todas partes, generan problemas para lo siguiente:

• Sitios con varios dominios: Los usuarios no pueden usar la misma llave de acceso para acceder a diferentes dominios específicos de cada país (por ejemplo, example.com y example.co.uk) administrados por la misma empresa.
• Dominios de marca: Los usuarios no pueden usar la misma credencial en diferentes dominios que usa una sola marca (por ejemplo, acme.com y acmerewards.com).
• Apps para dispositivos móviles: Las apps para dispositivos móviles a menudo no tienen su propio dominio, lo que dificulta la administración de credenciales.

Existen soluciones alternativas basadas en la federación de identidades y otras basadas en iframes, pero son inconvenientes en algunos casos. Las solicitudes de origen relacionadas ofrecen una solución.

Solución

Con solicitudes de origen relacionadas, un sitio web puede especificar los orígenes permitidos para usar su ID de RP.

Esto permite que los usuarios reutilicen la misma llave de acceso en varios sitios que operas.

Para usar las solicitudes de origen relacionadas, debes entregar un archivo JSON especial en una URL específica https://{RP ID}/.well-known/webauthn. Si example.com quiere permitir que los orígenes adicionales lo usen como un ID de RP, debe entregar el siguiente archivo en https://example.com/.well-known/webauthn:

{
  "origins": [
    "https://example.co.uk",
    "https://example.de",
    "https://example-rewards.com"
  ]
}

La próxima vez que cualquiera de estos sitios realice una llamada para la creación de llaves de acceso (navigator.credentials.create) o la autenticación (navigator.credentials.get) que use example.com como un ID de RP, el navegador notará un ID de RP que no coincide con el origen solicitante. Si el navegador admite solicitudes de origen relacionadas, primero busca un archivo webauthn en https://{RP ID}/.well-known/webauthn. Si el archivo existe, el navegador verifica si el origen que realiza la solicitud está en la allowlist. Si es así, continúa con los pasos de creación o autenticación de la llave de acceso.

Si el navegador no admite solicitudes de origen relacionadas, arroja un SecurityError.

Navegadores compatibles

Las solicitudes de origen relacionadas son compatibles con Chrome y Safari. A partir de enero de 2026, Firefox aún está considerando la función. Puedes hacer un seguimiento de su estado en el problema de posición de los estándares de Mozilla.

Configura las solicitudes de origen relacionadas

En la siguiente demostración, se usan dos sitios: https://ror-1.glitch.me y https://ror-2.glitch.me. Para permitir que los usuarios accedan con la misma llave de acceso en ambos sitios, se usan solicitudes de origen relacionadas para permitir que ror-2.glitch.me use ror-1.glitch.me como su ID de RP.

Demostración

https://ror-2.glitch.me implementa solicitudes de origen relacionadas para usar ror-1.glitch.me como un ID de RP, por lo que ror-1 y ror-2 usan ror-1.glitch.me como un ID de RP cuando se crea una llave de acceso o se autentica con ella. También implementamos una base de datos de llaves de acceso compartida en estos sitios.

Observa la siguiente experiencia del usuario:

• Puedes crear una llave de acceso y autenticarte con ella en ror-2, incluso si su ID de RP es ror-1 (y no ror-2).
• Una vez que creas una llave de acceso en ror-1 o ror-2, puedes autenticarte con ella en ambos sitios.ror-1ror-2 Debido a que ror-2 especifica ror-1 como un ID de RP, realizar una solicitud de creación o autenticación de llaves de acceso desde cualquiera de estos sitios es lo mismo que realizar la solicitud en ror-1. El ID de RP es lo único que vincula una solicitud a un origen.
• Una vez que creas una llave de acceso en ror-1 o ror-2, Chrome puede completarla automáticamente en ambos sitios.ror-1ror-2
• Una credencial creada en cualquiera de estos sitios tendrá un ID de RP de ror-1.

Consulta el código:

• Consulta el archivo /.well-known/webauthn configurado en la base de código ror-1.
• Consulta las instancias de RP_ID_ROR en la base de código ror-2.

Paso 1: Implementa una base de datos de cuentas compartida

Si quieres que tus usuarios puedan acceder con la misma llave de acceso en site-1 y site-2, implementa una base de datos de cuentas que se comparta entre estos dos sitios.

Paso 2: Configura tu archivo JSON .well-known/webauthn en site-1

Primero, configura site-1.com de modo que permita que site-2.com lo use como un ID de RP. Para ello, crea tu archivo JSON webauthn:

{
    "origins": [
        "https://site-2.com"
    ]
}

El objeto JSON debe contener una clave llamada orígenes cuyo valor sea un array de una o más cadenas que contengan orígenes web.

Limitación importante: Máximo 5 etiquetas

Cada elemento de esta lista se procesará para extraer la etiqueta eTLD + 1. Por ejemplo, las etiquetas eTLD + 1 de example.co.uk y example.de son ambas example. Sin embargo, la etiqueta eTLD + 1 de example-rewards.com es example-rewards. En Chrome, la cantidad máxima de etiquetas es 5.

Paso 3: Entrega tu JSON .well-known/webauthn en site-1

Luego, entrega tu archivo JSON en site-1.com/.well-known/webauthn.

Por ejemplo, en express:

app.get("/.well-known/webauthn", (req, res) => {
  const origins = {
    origins: ["https://site-2.com"],
  };
  return res.json(origins);
});

Aquí, usamos express res.json, que ya establece el correcto content-type ('application/json');

Paso 4: Especifica el ID de RP en site-2

En tu base de código site-2, establece site-1.com como el ID de RP en todos los lugares necesarios:

• Al crear credenciales:
  • Establece site-1.com como el ID de RP en las options de creación de credenciales que se pasan a la llamada de frontend navigator.credentials.create y que, por lo general, se generan del lado del servidor.
  • Establece site-1.com como el ID de RP esperado, ya que ejecutas verificaciones de credenciales antes de guardarlo en tu base de datos.
• Al autenticar:
  • Establece site-1.com como el ID de RP en las options de autenticación que se pasan a la llamada de frontend navigator.credentials.get y que, por lo general, se generan del lado del servidor.
  • Establece site-1.com como el ID de RP esperado que se verificará en el servidor, ya que ejecutas verificaciones de credenciales antes de autenticar al usuario.

Solución de problemas

Otras consideraciones

Comparte llaves de acceso en sitios y apps para dispositivos móviles

Las solicitudes de origen relacionadas permiten que los usuarios reutilicen una llave de acceso en varios sitios. Para permitir que los usuarios reutilicen una llave de acceso en un sitio web y una app para dispositivos móviles, usa las siguientes técnicas:

• En Chrome: Vínculos de recursos digitales Links. Obtén más información en Agrega compatibilidad con Vínculos de recursos digitales.
• En Safari: Dominios asociados.

Comparte contraseñas en sitios

Las solicitudes de origen relacionadas permiten que los usuarios reutilicen una llave de acceso en los sitios. Las soluciones para compartir contraseñas en los sitios varían entre los administradores de contraseñas. Para el Administrador de contraseñas de Google, usa Vínculos de recursos digitales . Safari tiene un sistema diferente.

Función de los administradores de credenciales y los agentes de usuario

Esto va más allá de tu alcance como desarrollador de sitios, pero ten en cuenta que, a largo plazo, el ID de RP no debería ser un concepto visible para el usuario en el agente de usuario o el administrador de credenciales que usan tus usuarios. En cambio, los agentes de usuario y los administradores de credenciales deberían mostrar a los usuarios dónde se usaron sus credenciales. Este cambio tardará en implementarse. Una solución temporal sería mostrar el sitio web actual y el sitio de registro original.