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

Maud Nalpas

El problema que resuelven las solicitudes de origen relacionadas

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

Esto se especifica en el grupo de confianza. ID (ID de RP), 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 evitan que las llaves de acceso se usen como una única credencial para autentican en todas partes, crean problemas para:

• Sitios con varios dominios: Los usuarios no pueden usar la misma llave de acceso para lo siguiente: accedan a diferentes dominios específicos de países (por ejemplo, example.com y example.co.uk) administradas por la misma empresa.
• Dominios de marca: Los usuarios no pueden usar la misma credencial en diferentes dominios utilizados por una sola marca (por ejemplo, acme.com y acmerewards.com).
• Aplicaciones para dispositivos móviles: A menudo, las aplicaciones para dispositivos móviles no tienen su propio dominio, lo que dificulta y la administración de credenciales.

Hay soluciones alternativas basadas en la federación de identidades como iframe, pero no es conveniente en algunos casos. Oferta de solicitudes de origen relacionadas una solución.

Nota: Los IDs de RP proporcionan credenciales independientes entre diferentes sitios web, pero en realidad proviene de la verificación del origen del sitio web en el campo CollectedClientData.

Solución

Con Solicitudes de origen relacionadas, un sitio web puede especificar orígenes autorizados para usar su ID de RP.

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

Para usar solicitudes de origen relacionadas, debes entregar un archivo JSON especial en un 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, debería publicar la 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 crear llaves de acceso (navigator.credentials.create) o autenticación (navigator.credentials.get) que usa 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 Origen relacionado Solicitudes, primero busca un webauthn en https://{RP ID}/.well-known/webauthn. Si el archivo existe, el navegador verifica si el origen que realiza la solicitud está incluido en la lista de entidades permitidas de ese . Si es así, se continúa con los pasos de creación de llaves de acceso o autenticación. Si el navegador no admite solicitudes de origen relacionados, arroja una SecurityError.

Navegadores compatibles

• Chrome: Compatible a partir de Chrome 128.
• Safari: Compatible a partir de macOS 15 beta 3 y en dispositivos móviles iOS 18 beta 3.
• Firefox: Esperando posición.

Advertencia: Desde agosto de 2024, las solicitudes de origen relacionadas no son compatibles con Firefox. getClientCapabilities aún no está disponible para que detectes la función faltante e implementes un como resguardo. Si implementas solicitudes de origen relacionadas, los usuarios de Firefox no podrán crear una llave de acceso (o acceder con ella) en los dominios con la intención de usar otro sitio como Se arroja un ID de RP y una SecurityError.

Cómo configurar solicitudes de origen relacionadas

En la siguiente demostración, se usa el ejemplo de 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, usa solicitudes de origen relacionados para permitir que ror-2.glitch.me use ror-1.glitch.me como su ID de RP.

Demostración

Nota: Abre la demostración en uno de los navegadores compatibles.

https://ror-2.glitch.me implementa solicitudes de origen relacionados para usar ror-1.glitch.me como ID de RP, por lo que tanto ror-1 como ror-2 usan ror-1.glitch.me como un ID de RP cuando se crea una llave de acceso o se autentica con él.
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 de forma correcta en ror-2, aunque el ID de la RP sea ror-1 (y no ror-2).
• Una vez que crees una llave de acceso en ror-1 o ror-2, podrás autenticarte con ella en ror-1 y ror-2. Debido a que ror-2 especifica ror-1 como un ID de RP, realizar una solicitud de autenticación o creación de llave de acceso desde cualquiera de estos sitios es lo mismo que realizar la solicitud en ror-1. El ID del RP es lo único que vincula una solicitud a un origen.
• Una vez que crees una llave de acceso en ror-1 o ror-2, Chrome podrá autocompletarla en ror-1 y ror-2.
• Las credenciales creadas en cualquiera de estos sitios tendrán un ID de RP de ror-1.

Gracias a las solicitudes de origen relacionadas, los usuarios pueden usar la misma credencial de llave de acceso en ror-1 y ror-2. Chrome también autocompletará las credenciales.

Ver código:

• Consulta la configuración del archivo ./well-known/webauthn en la base de código ror-1.
• Consulta los casos de RP_ID_ROR en la base de código ror-2.

Nota: En esta demostración, para simplificar, no se realiza ninguna verificación de contraseñas de forma interna. La demostración se enfoca en las llaves de acceso.

Paso 1: Implementa una base de datos de cuenta compartida

Si quieres que los usuarios accedan con la misma llave de acceso en site-1 y site-2, implementan una base de datos de cuentas compartida entre estos entre dos sitios.

Paso 2: Configura el 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 la RP. Para hacerlo, crea el archivo JSON webauthn:

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

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

Limitación importante: Se permite un máximo de 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.

Advertencia: Si tu lista incluye demasiadas etiquetas (más de 5), la cantidad excesiva elementos se ignorarán.

Paso 3: Publica el JSON .well-known/webauthn en site-1

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

Precaución: El archivo debe entregarse con un tipo de contenido de application/json y contener un una sola lista de objetos JSON orígenes permitidos. El formato correcto del archivo es /.well-known/webauthn (no incluyas la extensión .json).

Por ejemplo, en Express:

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

Aquí usamos res.json exprés, que ya establece la correcto content-type ('application/json');

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

En tu base de código site-2, configura site-1.com como el ID de RP en cualquier lugar que sea necesario:

• Después de crear la credencial:
  • Establece site-1.com como el ID de RP en la creación de la credencial. options que se pasan a navigator.credentials.create llamada a frontend y, por lo general, se generan del lado del servidor.
  • Establece site-1.com como el ID de RP esperado, a medida que ejecutes la credencial. verificaciones antes de guardarlas en tu base de datos.
• Después de la autenticación:
  • Establece site-1.com como el ID de RP en el objeto options de autenticación. que se pasan a la llamada de frontend navigator.credentials.get que se suele generar del servidor.
  • Establece site-1.com como el ID de RP que se espera que se verifique en el mientras ejecutas verificaciones de credenciales antes de autenticar al usuario.

Nota: ¿Qué sucede con origin? ¿Y la parte restringida name? En tu base de código site-2, el origin esperado debe permanecer sin cambios. (https://site-2.com), ya que designa el lugar en el que se espera que la solicitud de la que debe provenir la columna. Según el nombre de la RP (rp.name), no se usa en la práctica. Puedes dejarlo vacío.

Soluciona problemas

Mensaje de error en Chrome después de crear la credencial. Se produce este error si el archivo `.well-known/webauthn` no se puede encontrar en `https://{RP ID}/.well-known/webauthn`.

. Mensaje de error en Chrome después de crear la credencial. Se produce este error si se puede encontrar tu archivo `.well-known/webauthn`, pero no se muestra el origen desde el que intentas crear una credencial.

Otras consideraciones

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

Las solicitudes de origen relacionados permiten que tus usuarios reutilicen una llave de acceso en varias de la aplicación. Para permitir que los usuarios reutilicen una llave de acceso en un sitio web y una app para dispositivos móviles, haz lo siguiente: puedes usar las siguientes técnicas:

• En Chrome: Recurso digital Vínculos Más información en Agregar compatibilidad con Vínculos de recursos digitales
• En Safari: Dominios asociados:

Cómo compartir contraseñas entre sitios

Las solicitudes de origen relacionados permiten que tus usuarios reutilicen una llave de acceso en diferentes sitios. Las soluciones para compartir contraseñas entre sitios varían según el administrador de contraseñas. En el Administrador de contraseñas de Google, usa Vínculos de recursos digitales . Safari tiene un sistema diferente.

Rol de los administradores de credenciales y usuarios-agentes

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