Administra llaves de acceso en varios dominios y apps con el ID de RP

Eiji Kitamura

En WebAuthn y las llaves de acceso, el ID del grupo de confianza (RP ID) especifica el alcance de una credencial por el nombre de dominio. Cuando creas una llave de acceso, el navegador la vincula a un ID de RP específico. Luego, el navegador impide el uso de esa llave de acceso en un dominio que no coincida con ese ID o que no esté dentro de su alcance. Definir tu ID de RP correctamente garantiza una experiencia de llave de acceso fluida en subdominios, orígenes de sitios cruzados y apps para dispositivos móviles de origen.

Conceptos básicos sobre el ID de RP

El ID de entidad de confianza (ID de RP) es una cadena única que identifica tu servicio o sitio web. Un ID de RP debe ser una cadena de dominio. Puede ser el nombre de host actual exacto o un dominio principal más amplio, siempre que sea un eTLD+1 o superior. No puedes usar direcciones IP ni sufijos públicos (eTLDs) como ID de RP.

Por ejemplo, si alojas tu servidor en https://www.example.com, puedes usar example.com o www.example.com como su ID de RP, según las necesidades específicas. En la siguiente tabla, se muestran ejemplos de IDs de RP permitidos según el host de origen:

Host de origen ID de RP permitido (eTLD+1)
https://login.example.com example.com o login.example.com
https://example.com:8080 example.com (se excluyen los números de puerto)
https://mobile.example.co.jp example.co.jp o mobile.example.co.jp
https://sub.project.org.uk project.org.uk o sub.project.org.uk
https://user.github.io user.github.io (github.io es un eTLD)
https://myapp.pages.dev myapp.pages.dev (pages.dev es un eTLD)
http://localhost localhost (una excepción al requisito de HTTPS)

Cuando creas llaves de acceso, el navegador las vincula de forma criptográfica al ID de RP. Para usar una credencial, el origen de la solicitud de autenticación debe coincidir con ese ID de RP.

Cuando usas un eTLD+1 como ID de RP, la llave de acceso funciona en todos los subdominios relacionados. Por ejemplo, un ID de RP de example.com funciona para https://login.example.com y https://shop.example.com. Un RPID más específico, como login.example.com, funciona en su origen exacto, pero no en https://shop.example.com.

ID de RP en contextos entre sitios

Si tu servicio abarca varios eTLD+1 (por ejemplo, example.com y example.co.jp), se trata de una configuración entre sitios. Los IDs de RP estándar no admiten configuraciones en varios sitios.

Para compartir llaves de acceso entre sitios distintos, usa Related Origin Requests (ROR). ROR te permite compartir llaves de acceso entre sitios distintos porque el cliente (navegador) reconoce diferentes orígenes como parte del mismo servicio lógico.

Requisitos para el ROR:

  • Elige un ID de RP: Debes elegir un ID de RP y usarlo en todos los sitios.
  • Aloja un archivo de configuración: El dominio del ID de RP principal debe alojar un archivo de configuración en /.well-known/webauthn que enumere los orígenes autorizados.
  • Mantén la coherencia: Incluso si el usuario está en https://www.example.co.jp, el rpId en la llamada de WebAuthn debe ser el principal (por ejemplo, example.com) tanto en la creación como en la autenticación.

Ejemplo de ROR para el ID de RP example.com: https://example.com/.well-known/webauthn

{
  "origins": [
    "https://www.example.co.jp",
    "https://shop.example"
  ]
}

Para obtener más información sobre los detalles de implementación de las solicitudes de origen relacionadas, consulta Permite la reutilización de llaves de acceso en tus sitios con solicitudes de origen relacionadas.

ID de RP en apps para dispositivos móviles

Las aplicaciones para dispositivos móviles pueden usar llaves de acceso asociándose a un dominio web. Debes alojar un archivo de verificación en tu servidor para establecer esta relación.

El Credential Manager de Android requiere un archivo de vínculo de recursos digitales (DAL) en el dominio del ID de RP para asociarlo con la app.

  • Alojamiento: Aloja el archivo en https://<RP ID>/.well-known/assetlinks.json.
  • Verificación: Verifica el origin en clientDataJSON. En Android, es una cadena, como android:apk-key-hash:<hash>.

Ejemplo de DAL para el ID de RP example.com (alojado en https://example.com/.well-known/assetlinks.json)

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.google.credentialmanager.sample",
      "sha256_cert_fingerprints": [
        "4F:20:47:1F:D9:9A:BA:96:47:8D:59:27:C2:C8:A6:EA:8E:D2:8D:14:C0:B6:A2:39:99:9F:A3:4D:47:3D:FA:11"
      ]
    }
  }
]

Para obtener más información, consulta Cómo configurar vínculos de recursos digitales entre tu app y tu sitio web.

iOS: Dominios asociados

Las plataformas de Apple requieren un archivo apple-app-site-association (AASA) en el dominio del ID de RP para asociarse con la app.

  • Archivo AASA: Host https://<RP_ID>/.well-known/apple-app-site-association.
  • Derechos: Agrega webcredentials:<app info> a los derechos de la app.

Ejemplo de AASA para el ID de RP example.com: https://example.com/.well-known/apple-app-site-association:

{
  "webcredentials":
    {
      "apps": ["EXAMPLE123.com.example.passkey"]
    }
}

Para obtener más información, consulta Cómo conectarse a un servicio con llaves de acceso en la documentación para desarrolladores de Apple.

Resumen

El ID de RP determina dónde acceden tus usuarios a sus llaves de acceso. Ten en cuenta estos puntos durante la implementación:

  • Jerarquía y subdominios: El ID de RP debe ser una cadena de dominio (eTLD+1 o superior). Usar un dominio más amplio, como example.com, permite que las llaves de acceso funcionen en todos los subdominios (por ejemplo, login.example.com y shop.example.com).
  • Soluciones en varios sitios: Usa solicitudes de origen relacionadas (ROR) para los servicios que abarcan varios eTLD+1. Esto requiere un ID de RP y un archivo de configuración en /.well-known/webauthn.
  • Integración para dispositivos móviles: Establece una relación verificada entre tu sitio web y tus apps para dispositivos móviles con un archivo de Vínculos de recursos digitales (DAL) en /.well-known/assetlinks.json para Android y un archivo de asociación de sitio y app de Apple (AASA) en /.well-known/apple-app-site-association para iOS.

Más información