--- url: 'https://www.corbado.com/es/blog/webauthn-relying-party-id-rpid-claves-de-acceso' title: 'WebAuthn Relying Party ID (rpID) y claves de acceso: dominios y aplicaciones nativas' description: 'Este artículo explica el WebAuthn Relying Party ID para la autenticación con claves de acceso. Describe su configuración, la coincidencia de dominios y las aplicaciones nativas.' lang: 'es' author: 'Vincent Delitz' date: '2026-06-15T13:55:26.548Z' lastModified: '2026-06-16T06:03:17.703Z' keywords: 'relying party id, claves de acceso, passkeys, webauthn, autenticación, phishing' category: 'WebAuthn Know-How' --- # WebAuthn Relying Party ID (rpID) y claves de acceso: dominios y aplicaciones nativas ## Key Facts - El **Relying Party ID** es un dominio incrustado en cada clave de acceso. La autenticación falla si el origen del navegador no coincide, lo que hace que las claves de acceso sean altamente resistentes al phishing. - El **RP ID** no debe estar en la **Public Suffix List** y cambiarlo invalida todas las claves de acceso existentes. Utilice el dominio raíz por defecto para estar preparado para el futuro. - Las aplicaciones de iOS requieren un archivo **apple-app-site-association** en `/.well-known/` bajo el RP ID. Android requiere **assetlinks.json** en la misma ruta. Los nuevos archivos pueden tardar hasta 24 horas en almacenarse en la caché. - Múltiples dominios raíz necesitan **Related Origin Requests** a través de `.well-known/webauthn` para compartir claves de acceso. Utilice un único servidor WebAuthn con un solo RP ID para todas las aplicaciones, web y nativas. ## 1. Introducción La [autenticación](https://www.corbado.com/es/glossary/jwks) mediante [claves de acceso](https://www.corbado.com/es/glossary/cda) se está convirtiendo rápidamente en la norma a medida que gigantes tecnológicos como [TikTok](https://www.corbado.com/blog/tiktok-passkeys), GitHub, [WhatsApp](https://www.corbado.com/blog/whatsapp-passkeys), X (Twitter), [LinkedIn](https://www.corbado.com/blog/linkedin-passkeys) y Amazon las implementan o ya lo han hecho. Es evidente que el mundo tecnológico está reconociendo la importancia de una [autenticación](https://www.corbado.com/es/glossary/jwks) sencilla y segura. Más allá de la experiencia de usuario fluida al autenticarse con [Face ID](https://www.corbado.com/faq/is-face-id-passkey), Touch ID o [Windows Hello](https://www.corbado.com/glossary/windows-hello), las [claves de acceso](https://www.corbado.com/es/glossary/cda) ofrecen una [seguridad](https://www.corbado.com/es/blog/contrasenas-complejas-descifradas-pronto) incomparable en comparación con los métodos de [autenticación](https://www.corbado.com/es/glossary/jwks) tradicionales como las [contraseñas](https://www.corbado.com/es/blog/brecha-datos-lastpass). Una de las características más destacadas es su fuerte resistencia al [phishing](https://www.corbado.com/glossary/phishing). Un ataque de [phishing](https://www.corbado.com/glossary/phishing) es aquel en el que se engaña a la víctima para que proporcione credenciales a un sitio falso que simula ser el original. Por ejemplo, imagine recibir un correo electrónico de lo que parece ser su banco, pidiéndole que inicie sesión. Usted hace clic en el enlace y el sitio [web](https://www.corbado.com/es/blog/proveedores-passkeys) parece legítimo, por lo que introduce sus credenciales y el atacante puede usarlas para iniciar sesión en el sitio original. Esto se está convirtiendo en un problema cada vez mayor en la era digital e incluso grandes empresas como [Okta](https://www.darkreading.com/application-security/okta-flaw-involved-mgm-resorts-breach-attackers-claim) (¡un proveedor de autenticación!) o [Retool](https://retool.com/blog/mfa-isnt-mfa/) han sido víctimas de ataques de spear-[phishing](https://www.corbado.com/glossary/phishing) (una forma especial de phishing en la que se ataca a víctimas específicas con trucos de phishing muy personales), lo que enfatiza la necesidad de medidas de [seguridad](https://www.corbado.com/es/blog/contrasenas-complejas-descifradas-pronto) sólidas. Por el contrario, si utiliza una [clave de acceso](https://www.corbado.com/es/blog/proveedores-passkeys) y el sitio es falso, su autenticación fallará. Esto se debe a que las [claves de acceso](https://www.corbado.com/es/glossary/cda) están vinculadas a los dominios para los que fueron creadas a través del **Relying Party ID**. > No puede iniciar sesión con una [clave de acceso](https://www.corbado.com/es/blog/proveedores-passkeys) en > ningún otro sitio, lo que hace que las claves de acceso sean altamente resistentes al > phishing (aunque ningún sistema es absolutamente inmune a todos los vectores de ataque). Este mecanismo está integrado en WebAuthn, el estándar [web](https://www.corbado.com/es/blog/proveedores-passkeys) subyacente a las claves de acceso para la [autenticación sin contraseña](https://www.corbado.com/es/faq/passkeys-sin-biometria). WebAuthn se basa en dos ceremonias principales: la ceremonia de registro y la de autenticación. Durante la ceremonia de registro se crea una nueva [clave de acceso](https://www.corbado.com/es/blog/proveedores-passkeys) para un servicio en línea (el [Relying Party](https://www.corbado.com/glossary/relying-party)) a través de una aplicación [web](https://www.corbado.com/es/blog/proveedores-passkeys) o nativa. En este proceso, el dominio (Relying Party ID) para el que se crea la clave de acceso se almacena en la clave de acceso. Esto permite que la ceremonia de autenticación compruebe si el servicio en línea (el [Relying Party](https://www.corbado.com/glossary/relying-party)), al que pertenece la aplicación web o nativa, coincide con el [Relying Party](https://www.corbado.com/glossary/relying-party) ID almacenado en la clave de acceso. A continuación, veremos en detalle cómo funciona este [proceso de coincidencia de dominios](#what-relying-party-id) y cómo se protegen las aplicaciones nativas en particular. ## 2. ¿Qué es el Relying Party ID? El [**Relying Party ID**](https://www.w3.org/TR/webauthn-2/#relying-party-identifier) es esencialmente un dominio almacenado dentro de la clave de acceso, lo que garantiza que la clave de acceso solo funcione si la URL actual del navegador (el origen del usuario que se envía automáticamente en cada solicitud) coincide con ella (consulte el enfoque de la [aplicación nativa](https://www.corbado.com/es/blog/passkeys-aplicaciones-nativas-webview) [a continuación](#integration-options-native-apps)). Es un componente crucial de la especificación WebAuthn, en la que puede profundizar [aquí](https://www.w3.org/TR/webauthn-2/). El Relying Party ID puede ser el dominio raíz (p. ej., `corbado.com`) o un subdominio (`auth.corbado.com`). No puede almacenar el dominio raíz como Relying Party ID si se encuentra en la lista de sufijos públicos (encuentre la lista y las bibliotecas para la detección de sufijos públicos [aquí](https://publicsuffix.org/learn/)). Cambiar el Relying Party ID de un servicio en línea inutilizará las claves de acceso existentes (excepciones: el nuevo Relying Party ID es un subdominio del antiguo Relying Party ID, o se configuran solicitudes de origen relacionadas (Related Origin Requests) a través de `.well-known/webauthn` para permitir la reutilización de claves de acceso en dominios relacionados). Durante el proceso de autenticación, el Relying Party ID se compara con la URL del navegador (origen del usuario) para garantizar que coincidan. Coincidir en este sentido significa que: - La URL del navegador (origen del usuario) coincide exactamente con el Relying Party ID O - La URL del navegador (origen del usuario) es un subdominio que coincide con el Relying Party ID y el dominio principal es registrable (p. ej., `com` o cualquier dominio en la Public Suffix List no funciona) A continuación, se muestra un esquema detallado de qué _originalHost_ (segunda columna) tiene permiso para acceder a su dominio principal: ![relying party id table](https://www.corbado.com/website-assets/relying_party_id_table_4c98cc04f4.jpg) A continuación, puede ver el objeto [**PublicKeyCredentialCreationOptions**](https://www.w3.org/TR/webauthn-2/#iface-pkcredential) analizado: ```json { "publicKey": { "attestation": "direct", "authenticatorSelection": { "authenticatorAttachment": "platform", "requireResidentKey": false, "userVerification": "preferred" }, "challenge": "qNqrdXUrk5S7dCM1MAYH3qSVDXznb-6prQoGqiACR10=", "excludeCredentials": [], "pubKeyCredParams": [ { "alg": -7, "type": "public-key" } ], "rp": { "id": "corbado.com", "name": "Corbado" }, "timeout": 30000, "user": { "displayName": "Corbado user", "id": "bz9ZDfHzOBLycqISTAdWwWIZt8VO-6mT3hBNXS5jwmY=" } } } ``` `rp` significa Relying Party. Uno de los principales beneficios del Relying Party ID es la prevención de ataques de phishing. Imagine el siguiente escenario: 1. Un atacante desarrolla un clon de [PayPal](https://www.corbado.com/blog/paypal-passkeys) que es un sitio web falso que intenta robar sus credenciales de [PayPal](https://www.corbado.com/blog/paypal-passkeys) para iniciar sesión en su nombre y enviar dinero a la cuenta del atacante. Este sitio web falso de [PayPal](https://www.corbado.com/blog/paypal-passkeys) está alojado en el dominio paybal.com (por lo que a menudo no es visible que es un dominio diferente a primera vista). 2. Usted ya ha creado una clave de acceso en el pasado para el sitio legítimo de PayPal. Esta clave de acceso almacenó el Relying Party ID paypal.com. 3. Usted visita el sitio web falso de PayPal en paybal.com (al visitar este sitio, el origen de su solicitud es paybal.com\*) y el sitio envía a su dispositivo (el autenticador) un desafío para el Relying Party ID `paypal.com` (aquí intenta engañarle) y le pide que lo firme con su clave de acceso para el Relying Party ID paypal.com. 4. Su dispositivo (el autenticador) comprueba si el origen de la solicitud (`paypal.com`) y el Relying Party ID que almacenó en la clave de acceso (`paypal.com`) coinciden. 5. Como obviamente no coinciden, la autenticación falla y le evita dar acceso a un atacante a su cuenta de PayPal. El siguiente diagrama ilustra este mecanismo de prevención de phishing. _En el caso de una aplicación nativa, el manejo del origen difiere según la plataforma: en Android, el origen se formatea como `android:apk-key-hash:`. En iOS, el origen web de WebAuthn es el origen web del RP (p. ej., `https://paypal.com`). En ambos casos, la confianza entre su aplicación nativa y el servidor se verifica a través del archivo de asociación correspondiente (consulte [a continuación](#configuring-relying-party-native-apps)). Para obtener información detallada sobre cómo funciona la validación de origen para aplicaciones nativas, consulte nuestra guía sobre la validación de origen de WebAuthn para aplicaciones nativas._ ## 3. Las dos opciones de integración diferentes para aplicaciones nativas Para implementar claves de acceso en una [aplicación nativa](https://www.corbado.com/es/blog/passkeys-aplicaciones-nativas-webview), un desarrollador puede decidir entre agregarlas a través de un [WebView](https://www.corbado.com/blog/native-app-passkeys) o de forma nativa. Examinemos los beneficios y desventajas de ambos enfoques a continuación. ### 3.1 Integración de claves de acceso a través de WebView ![Passkey Integration WebView (GitHub)](https://www.corbado.com/website-assets/650c601b1eb462e25702a870_android_webview_passkey_github_8bc81d9852.jpg) El uso de un **WebView**\* para integrar claves de acceso significa integrar un navegador web dentro de la [aplicación nativa](https://www.corbado.com/es/blog/passkeys-aplicaciones-nativas-webview) para gestionar el proceso de autenticación. Este enfoque muestra esencialmente una página web dentro de la aplicación, lo que facilita la reutilización de flujos de autenticación basados en la web sin tener que reescribirlos para la plataforma nativa. Sin embargo, hay algunos inconvenientes. Es posible que los WebViews no admitan todas las características de las claves de acceso y existe un riesgo potencial de ataques de tipo "man-in-the-middle" si no se implementan de forma segura. Además, la experiencia del usuario puede no ser tan fluida como con las integraciones nativas y puede haber [desafíos](https://www.corbado.com/es/blog/passkeys-comprar-vs-desarrollar-guia) para mantener un comportamiento constante en diferentes dispositivos y versiones del sistema operativo. _\*Existen varios tipos de WebViews: en iOS (WKWebView, SFSafariViewController o SFAuthenticationSession / ASWebAuthenticationSession para flujos de autenticación basados en OAuth/OpenID Connect) y Android (WebView, CCT-Chrome Custom Tabs). Recomendamos usar SFSafariViewController/ASWebAuthenticationSession y Chrome Custom Tabs en el contexto de las claves de acceso si no desea una integración nativa._ ### 3.2 Integración nativa de claves de acceso ![Native Passkey Integration (Kayak)](https://www.corbado.com/website-assets/650c625cac723f594137a029_android_native_passkey_kayak_0f689e761e.jpg) La **integración nativa** implica la creación de la funcionalidad de la clave de acceso directamente en la aplicación de [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) o [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) utilizando API y bibliotecas específicas de la plataforma. Este método ofrece una experiencia de usuario más fluida, ya que no hay necesidad de hacer la transición entre la aplicación nativa y un [WebView](https://www.corbado.com/blog/native-app-passkeys). También permite un mejor rendimiento y una apariencia más coherente. Desde el punto de vista de la [seguridad](https://www.corbado.com/es/blog/contrasenas-complejas-descifradas-pronto), la integración nativa puede ofrecer una protección mejorada contra ciertos tipos de ataques, especialmente cuando se combina con características de seguridad específicas de la plataforma. Sin embargo, el esfuerzo de implementación puede ser mayor, ya que los desarrolladores deben escribir y mantener un código separado para cada plataforma (Android e [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)). Además, mantenerse actualizado con las últimas especificaciones de claves de acceso / WebAuthn puede requerir actualizaciones de la aplicación más frecuentes. A continuación, nos centraremos en la integración nativa de claves de acceso. ## 4. Configuración del Relying Party para aplicaciones nativas Las aplicaciones nativas (p. ej., aplicaciones de iOS o [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)) presentan un desafío en comparación con las aplicaciones web. A diferencia de las aplicaciones web, no hay una URL del navegador que coincida con el Relying Party ID. Sin embargo, para garantizar el mismo nivel de seguridad, los dominios se conectan a las aplicaciones nativas a través de **archivos de asociación**, de modo que se establezca la confianza entre un dominio y una aplicación nativa. Esto es especialmente importante si se creó una clave de acceso en una aplicación web y debe usarse para el mismo Relying Party ID en una aplicación nativa (y viceversa). ### 4.1 Archivos de asociación en iOS: apple-app-site-association iOS utiliza el archivo apple-app-site-association. Este archivo contiene varios derechos (entitlements), pero para WebAuthn y las claves de acceso, el derecho webcredentials es importante. ```json { "webcredentials": { "apps": ["9RF9KY88B2.com.corbado.passkeys"] } } ``` En webcredentials.apps, debe almacenar su prefijo de identificador de aplicación (Application Identifier Prefix, p. ej., `9RF9KY77B2`) y su identificador de paquete (Bundle Identifier, p. ej., `com.corbado.passkeys`). Para que funcionen las aplicaciones nativas de iOS, el archivo apple-app-site-association debe almacenarse en el directorio `/.well-known` de los Relying Party IDs (`https:///.well-known/apple-app-site-association`). Vea un ejemplo en vivo [aquí](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/apple-app-site-association). ### 4.2 Archivos de asociación en Android: assetlinks.json [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) utiliza el archivo `assetlinks.json`, que, al igual que su contraparte de iOS, requiere configuraciones específicas para WebAuthn y las claves de acceso. ```json [ { "relation": [ "delegate_permission/common.handle_all_urls", "delegate_permission/common.get_login_creds" ], "target": { "namespace": "android_app", "package_name": "com.corbado.passkeys.pub", "sha256_cert_fingerprints": [ "F8:90:4E:9A:99:01:71:75:25:38:D5:36:16:2D:B3:65:EB:41:51:D4:53:9A:72:BC:4B:56:C5:16:43:62:E2:C0" ] } } ] ``` Debe tener configurados los valores de relación `delegate_permission/common.handle_all_urls` y `delegate_permission/common.get_login_creds`. Además, debe agregar el nombre de su paquete y la huella digital SHA-256 de su certificado de firma. Para permitir el uso compartido de una clave de acceso entre una aplicación nativa y una aplicación web, debe agregar dos entradas. Una para el namespace web y otra para el namespace android_app. Vea un ejemplo en vivo [aquí](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/assetlinks.json). Para que funcionen las aplicaciones de Android, el archivo assetlinks.json debe almacenarse en el directorio `/.well-known` de los Relying Party IDs `https:///.well-known/assetlinks.json` (prácticamente igual que en iOS). Consulte este artículo del blog para ver una implementación de muestra que comparte claves de acceso entre una aplicación nativa de Android / iOS y una aplicación web. ## 5. Establecer la confianza entre una aplicación nativa y una aplicación web ### 5.1 iOS El proceso para establecer la confianza entre una aplicación iOS y una aplicación web es el siguiente: 1. El desarrollador de la aplicación iOS debe especificar una lista de dominios que desea asociar con la aplicación nativa. Estos dominios están codificados de forma rígida en los derechos (entitlements) de las aplicaciones de iOS, por ejemplo: - webcredentials:auth.Corbado.com - webcredentials:\*.Corbado.com 2. Cada vez que se instala o actualiza la aplicación de iOS, iOS descargará el archivo apple-app-site-association para cada entrada de la lista de derechos de la aplicación de iOS. 3. Cuando se crea una credencial (por ejemplo, una clave de acceso) dentro de una aplicación de iOS, la aplicación de iOS valida si el dominio del servidor del relying party está asociado con la aplicación de iOS verificando los siguientes dos aspectos: - ¿Existe un archivo `apple-app-site-association` para este dominio del servidor del relying party en el dispositivo? - ¿Aparece la aplicación de iOS en ese archivo `apple-app-site-association`? Si y solo si ambas preguntas pueden responderse con un sí, se puede [crear una clave de acceso](https://www.corbado.com/es/blog/como-lograr-alta-adopcion-passkeys-flujos-creacion) dentro de la aplicación de iOS. ### 5.2 Android El proceso para establecer la confianza entre una aplicación de Android y una aplicación web es el siguiente: 1. El desarrollador de la aplicación de Android debe especificar una lista de dominios que desea asociar con la aplicación de Android. Estos dominios se almacenan como objetivos (targets) con el espacio de nombres (namespace) web en el archivo assetlinks.json. Para declarar que las aplicaciones de Android y las aplicaciones web comparten credenciales, se debe especificar `delegate_permission/common.get_login_creds`. Encuentre detalles [aquí](https://developer.android.com/training/sign-in/passkeys#add-support-dal). 2. Si se crea una clave de acceso dentro de la aplicación de Android, la aplicación de Android valida si el Relying Party ID está asociado con la aplicación de Android comprobando el archivo `assetlinks.json`: - ¿Existe un archivo `assetlinks.json` para este Relying Party ID en `https://./well-known/assetlinks.json`? - ¿Está la aplicación de Android definida correctamente como un objetivo (target)? 3. Si y solo si ambas preguntas pueden responderse con un sí, se puede [crear una clave de acceso](https://www.corbado.com/es/blog/como-lograr-alta-adopcion-passkeys-flujos-creacion) dentro de la aplicación de Android. El siguiente diagrama compara estos procesos de establecimiento de confianza lado a lado. ## 6. Descripción general de la configuración para Android, iOS y Flutter A continuación, proporcionamos una descripción general detallada de las diferentes configuraciones que son necesarias para configurar correctamente la autenticación con claves de acceso para aplicaciones nativas. | Característica | iOS | Android | | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Guía oficial de implementación para la autenticación nativa con claves de acceso | Apple Developer | Google Developer | | Permite compartir claves de acceso con aplicaciones web | Sí, a través del archivo apple-app-site-association | Sí, a través de assetlinks.json | | Ubicación del archivo de asociación | [https://acme.com/.well-known/apple-app-site-association](https://acme.com/.well-known/apple-app-site-association) | [https://acme.com/.well-known/assetlinks.json](https://acme.com/.well-known/assetlinks.json) | | Archivo en caché | Sí (desde iOS 14), la sincronización inicial puede tardar hasta 24 horas | Sí (por Play Services) | | Posibilidad de evasión (bypass) | Sí, con sección de modo alternativo | No | | Probable con | Prueba de apple-app-site-association | Prueba de assetlinks.json | | Identificador de aplicación con ejemplo | `.`, p. ej. `T84QZS65DQ.com.facebook.Messenger` | Huella digital SHA256, p. ej. `E3:F9:E1:E0:CF:99:D0:E5:6A:05:5B:A6: 5E:24:1B:33:99: 7F:CE:A5:24:32: 6B:0C:DD:6E:C1:32: 7E:D0:FD:C1` | | Dónde encontrar el identificador de la aplicación | El prefijo del identificador de la aplicación del equipo se puede encontrar en la cuenta de desarrollador en developer.apple.com y el Bundle Identifier es el nombre exacto del proyecto de XCode | Cuando ya se ha cargado: Google Play Console > Gestión de versiones > Firma de aplicaciones Local: `keytool -list -v -keystore -alias -storepass -keypass ` | | Nombre de la sección que enlaza la aplicación con la web | applinks (no requerido para claves de acceso) | `delegate_permission/common.handle_all_urls` (requerido para claves de acceso) | | Nombre de la sección que permite el uso compartido de credenciales entre aplicación / web | webcredentials | `delegate_permission/common.get_login_creds` | | Registro de todos los archivos de asociación | Habilitar y agregar el dominio asociado en el entorno de desarrollo de XCode (configuración de propiedad para generar el archivo de derechos) | Al usar la API Credential Manager, no se requiere el registro de assetlinks.json en el manifiesto para las claves de acceso (aunque sí para las contraseñas). Cuando no se usa la API Credential Manager, debe enumerar los nombres de host con una entrada `` en AndroidManifest.xml en la actividad específica (parte del código fuente de la aplicación de Android). El `` debe tener autoVerify=true. | Para [Flutter](https://www.corbado.com/blog/flutter-passkeys-package), se aplica la regla respectiva de Android o iOS. La única configuración específica de [Flutter](https://www.corbado.com/blog/flutter-passkeys-package) es el registro de los archivos de asociación, donde debe agregar: - Para Android: [flutter_deeplinking_enabled en AndroidManifest.xml](https://docs.flutter.dev/cookbook/navigation/set-up-app-links) - Para iOS: [FlutterDeepLinkingEnabled true en Info.plist](https://docs.flutter.dev/cookbook/navigation/set-up-universal-links) ## 7. Ejemplos de Relying Party ID válidos e inválidos y archivos de asociación Como hemos experimentado nosotros mismos, trabajar con Relying Party IDs, diferentes niveles de (sub)dominios y CNAMEs puede ser una tarea bastante desafiante. Presentamos cuatro ejemplos distintos y explicamos por qué y cómo funcionan. Tenga en cuenta que la fila de la tabla CNAME no es necesaria para la autenticación con claves de acceso y es solo el resultado de nuestra investigación que queríamos agregar. ### 7.1 Ejemplo 1: El Relying Party es el dominio raíz | **Relying Party ID** | corbado.com | | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Entitlements (solo iOS)** | webcredentials:corbado.com | | **Ubicación del archivo apple-app-site-association** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **Ubicación del archivo assetlinks.json** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | N/A | En este ejemplo, el archivo `apple-app-site-association` / `assetlinks.json` para Corbado.com se puede descargar sin problemas cuando se instala / actualiza la aplicación nativa, porque el archivo se encuentra en la misma ubicación que el Relying Party ID. **Se puede crear una clave de acceso para el Relying Party ID.** ### 7.2 Ejemplo 2: El Relying Party es un subdominio y se ha establecido un CNAME | **Relying Party ID** | auth.corbado.com | | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Entitlements (solo iOS)** | webcredentials:auth.corbado.com | | **Ubicación del archivo apple-app-site-association** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **Ubicación del archivo assetlinks.json** | [https://pro-123.passkeys.eu/.well-known/assetlinks.json](https://pro-123.passkeys.eu/.well-known/assetlinks.json) | | **CNAME** | auth.corbado.com => pro-123.passkeys.eu | En este ejemplo, el archivo `apple-app-site-association` / `assetlinks.json` para auth.corbado.com se puede descargar sin problemas cuando se instala / actualiza la aplicación nativa, porque el archivo está en la ubicación como Relying Party ID, ya que el CNAME apunta desde el Relying Party ID a la ubicación almacenada. **Se puede crear una clave de acceso para el Relying Party ID.** ### 7.3 Ejemplo 3: El Relying Party es el dominio raíz y se ha establecido un CNAME | **Relying Party ID** | corbado.com | | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Entitlements (solo iOS)** | webcredentials:corbado.com; webcredentials:auth.corbado.com | | **Ubicación del archivo apple-app-site-association** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **Ubicación del archivo assetlinks.json** | [https://pro-123.passkeys.eu/.well-known/assetlinks.json](https://pro-123.passkeys.eu/.well-known/assetlinks.json) | | **CNAME** | auth.corbado.com => pro-123.passkeys.eu | En este ejemplo, el archivo `apple-app-site-association` / `assetlinks.json` para auth.corbado.com se puede descargar sin problemas cuando se instala / actualiza la aplicación nativa, porque el archivo está, debido al CNAME, en la ubicación donde `auth.corbado.com` lo espera. PERO: El archivo `apple-site-association-file` / `assetlinks.json` para corbado.com no se puede descargar cuando se instala / actualiza la aplicación nativa, porque el archivo no está en `https://corbado.com/.well-known/apple-app-site-association` / `https://corbado.com/.well-known/assetlinks.json`, donde se espera, y no hay ningún CNAME apuntando a él. **No se puede crear una clave de acceso para el Relying Party ID.** ### 7.4 Ejemplo 4: El Relying Party es un subdominio y se ha establecido un entitlement comodín (wildcard) | **Relying Party ID** | auth.corbado.com | | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Entitlements (solo iOS)** | webcredentials:\*.corbado.com | | **Ubicación del archivo apple-app-site-association** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **Ubicación del archivo assetlinks.json** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | N/A | En este ejemplo, el archivo `apple-app-site-association` para corbado.com se puede descargar sin problemas cuando se instala / actualiza la aplicación nativa, porque el archivo está donde se espera y el derecho webcredentials (`*.corbado.com`) coincide con el Relying Party ID (`auth.corbado.com`). Tenga en cuenta que este ejemplo no funciona para Android, ya que Android no funciona con derechos comodín. En general, no se recomienda esta forma de definir los Relying Party IDs. **Se puede crear una clave de acceso para el Relying Party ID.** ## 8. Errores comunes de Relying Party ID y cómo evitarlos ### 8.1 Cambiar el Relying Party ID de subdominio a dominio raíz **Error:** Comenzó a desarrollar y definió un subdominio (p. ej., `login.acme.com`) como su Relying Party ID. Los primeros usuarios crearon una clave de acceso para este Relying Party ID. Luego, se da cuenta de que también necesita estas claves de acceso para la autenticación en otro subdominio (p. ej., `app.acme.com`). Como el origen de un usuario y el Relying Party ID para el nuevo subdominio no coinciden, el usuario no puede iniciar sesión con la clave de acceso. Cambiar el Relying Party ID en la configuración de WebAuthn a `acme.com` invalidaría todas las claves de acceso existentes, ya que el nuevo origen y el Relying Party ID almacenado en las claves de acceso existentes no coinciden. **Solución:** Verifique dos veces inicialmente al definir su Relying Party ID, ya que esto es más o menos definitivo. Si no está seguro y desea estar preparado para el futuro, es decir, que otros subdominios en el futuro puedan necesitar la clave de acceso para la autenticación, le recomendamos que utilice el dominio raíz (p. ej., acme.com) como Relying Party ID a menos que se encuentre en la [Public Suffix List](https://publicsuffix.org/learn/). ### 8.2 Diferentes Relying Party IDs para aplicaciones web y nativas **Error:** Está desarrollando una aplicación web y nativa simultáneamente. Para acelerar las cosas, utiliza dos servidores WebAuthn diferentes (con diferentes Relying Party IDs para la aplicación nativa y web). Cuando sus usuarios crean las primeras claves de acceso, el respectivo Relying Party ID se almacena en la clave de acceso. Permitir el inicio de sesión en varios dispositivos / plataformas con la misma clave de acceso, por ejemplo, con una clave de acceso creada en una aplicación web e intentar iniciar sesión en una aplicación nativa, ya no es posible. La fusión de los dos servidores WebAuthn abandonará las claves de acceso que se registraron con el antiguo servidor WebAuthn (antiguo Relying Party ID) y sus usuarios no podrán iniciar sesión con estas claves de acceso. **Solución:** Si tiene varias aplicaciones (p. ej., una aplicación web y una aplicación nativa), tenga siempre un solo servidor WebAuthn y defina solo un Relying Party ID para todas sus aplicaciones. La vinculación entre estas aplicaciones se puede realizar a través de los pasos descritos anteriormente. ### 8.3 Archivos de asociación no válidos e inalcanzables **Error:** Comienza a desarrollar su aplicación, configuró los archivos de asociación y los implementó en su servidor. Por alguna razón, todavía recibe mensajes de error y no encuentra la causa principal. **Solución:** Una causa potencial para el mensaje de error podría ser un archivo de asociación mal formado o inalcanzable. Antes de implementar cualquier archivo de asociación en un servidor, recomendamos encarecidamente verificar la validez y la accesibilidad (a menudo estos archivos pueden estar detrás de [una VPN robusta](https://cybernews.com/best-vpn/most-secure-vpns/) o un firewall que impide el acceso adecuado a los rastreadores de Apple y Google) de un archivo de asociación a través de las herramientas proporcionadas para [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) y Android. ### 8.4 Archivo apple-app-site-association aún no almacenado en caché por la CDN de Apple **Error:** Implementó su archivo apple-app-site-association en su servidor y desea comenzar a crear inmediatamente una clave de acceso en su dispositivo de prueba. Por alguna razón, no puede crear la clave de acceso y recibe mensajes de error. **Solución:** La razón detrás de estos mensajes de error es que los dispositivos iOS descargan el archivo `apple-app-site-association` para validar el Relying Party. Para ello, los dispositivos iOS no envían una solicitud directa a su servidor, sino que utilizan una CDN. Tanto el dispositivo como la CDN almacenan en caché el archivo `apple-app-site-association` después de que se haya recuperado correctamente. Debido a esta funcionalidad de almacenamiento en caché, los nuevos cambios en su archivo `apple-app-site-association` no se reflejan directamente en su aplicación. Puede pasar hasta 24 horas hasta que la CDN almacene en caché el archivo `apple-app-site-association`. Para eludir esta restricción durante el desarrollo, puede agregar `?mode=developer` al Relying Party ID y desactivar completamente el almacenamiento en caché (p. ej., el Relying Party ID sería `acme.com?mode=developer`). ### 8.5 Emulador de Android e incompatibilidad con la versión de la API **Error:** Empieza a desarrollar una aplicación de Android y quiere probarla en un emulador de Android. Por alguna razón, recibe mensajes de error, aunque haya configurado correctamente el emulador de Android y otras aplicaciones parezcan funcionar sin problemas. **Solución:** Las versiones de Android, la compatibilidad con Play Store y las versiones de API juegan un papel importante al probar una aplicación de claves de acceso. Además, debe haber iniciado sesión en una cuenta de Google. ## 9. Recomendación ### 9.1 Recomendación general Nuestra recomendación general es elegir cuidadosamente su Relying Party ID en función del panorama y los requisitos de su aplicación. A continuación, hemos recopilado los casos de uso más comunes, pero nuestra recomendación general es que debe **intentar elegir su dominio raíz como su Relying Party ID** y configurar su autenticación de esta manera. Con Corbado, también lo hemos preconfigurado de esta manera para usted (ya que es parte de nuestro enfoque para ofrecer una autenticación de claves de acceso fluida para todas las configuraciones técnicas. Nuestros componentes de interfaz de usuario y SDK están preparados para usarse con su dominio raíz como Relying Party ID). | Caso | Recomendación | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **A) Tiene un dominio raíz:**

Ejemplo: acme.com

Todas las aplicaciones y la autenticación se ejecutan en este dominio raíz o en subdominios del mismo | ✔️ Elija el dominio raíz como su Relying Party ID, ya que esto no causará ningún problema para las aplicaciones web o nativas. | | **B) Tiene varios dominios raíz:**

Ejemplo: kayak.com, kayak.co.uk, kayak.de

Atiende a sus usuarios desde diferentes dominios de nivel superior internacionales. Kayak.com para EE. UU. y kayak.co.uk para el Reino Unido, o tiene dominios raíz completamente diferentes que deberían permitir a los mismos usuarios iniciar sesión con las mismas claves de acceso. | ⚠️ En sus aplicaciones web, compartir claves de acceso requiere la configuración de Related Origin Requests (solicitudes de origen relacionadas) a través de `.well-known/webauthn` para permitir que orígenes específicos usen un RP ID común (el soporte de los navegadores varía; verifique la compatibilidad). Alternativamente, elija un dominio raíz de autenticación común.

✔️ Puede conectar sus aplicaciones nativas a cualquier cantidad de dominios raíz siempre que tenga el control de los archivos de asociación raíz.

❌ En caso de que quiera migrar más tarde a otro dominio raíz para alojar su sitio web, no podrá usar sus claves de acceso ya creadas, porque tendrá que cambiar la marca y cambiar el dominio (Relying Party ID). | | **C) AÚN NO tiene un dominio raíz, se está ejecutando solo en backend o en un subdominio público. Hay algunos casos en los que esto podría suceder:**

1. Trabaja en un subdominio de libre disponibilidad, donde el dominio raíz no está bajo su control (el dominio raíz figura en [https://publicsuffix.org/](https://publicsuffix.org/)) por ejemplo, URL de CDN

2. Trabaja en una aplicación nativa. | ❌ En los subdominios públicos, no puede controlar los archivos de asociación en el nivel raíz del dominio raíz. Por lo tanto, las claves de acceso no funcionarán de forma nativa.

⚠️ La única forma de solucionar esto para algunos servicios es cambiar a un plan de pago, donde puede definir un CNAME u obtener un dominio raíz personalizado para usted. | ### 9.2 Recomendación al usar Corbado A continuación, proporcionamos un árbol de decisiones muy específico que debería ayudarlo a determinar el Relying Party ID correcto y cómo debe manejar / alojar archivos de asociación cuando usa Corbado como su solución de claves de acceso. La primera decisión es si se encuentra en un entorno de desarrollo o producción. El siguiente nivel de decisión que debe tomar se basa en el panorama de su aplicación: ¿tiene solo una aplicación nativa o una aplicación nativa y web? #### A) Desarrollo Para el entorno de desarrollo, asumimos que desea comenzar a desarrollar y probar rápidamente. El Relying Party ID se puede cambiar más tarde si desea pasar a producción. ##### A1) Solo nativo - Establezca Relying Party ID = `pro-XXX.frontendapi.cloud.corbado.io` (valor predeterminado) - Corbado aloja el archivo de asociación para usted - No hay tareas pendientes de DNS para usted ##### A2) Aplicación nativa y aplicación web No es fácilmente posible probar tanto la aplicación web como la aplicación nativa al mismo tiempo **Opción 1:** Puede establecer Relying Party ID = `pro-XXX.frontendapi.cloud.corbado.io` (la aplicación nativa funciona) O establecer Relying Party ID = `localhost` (la aplicación web funciona) **Opción 2:** La única solución para que las aplicaciones nativas y web funcionen al mismo tiempo es usar un proxy inverso local (es una solución un poco rudimentaria): - Establezca Relying Party ID = `acme-dev.com` - Establezca el CNAME de `acme-dev.com` => `pro-XXX.frontendapi.cloud.corbado.io` - Agregue la entrada local de `/etc/hosts` `localhost acme-dev.com` - Agregue un proxy inverso (nginx) con la regla para `acme-dev.com` => `localhost:3000` (como ejemplo) #### B) Producción En el entorno de producción, debe decidir si le parece bien un subdominio como Relying Party ID (p. ej., `auth.acme.com`) o si desea un dominio raíz como Relying Party ID (p. ej., `acme.com`) ##### B1) Subdominio como Relying Party ID ###### B1.1) Solo nativo - Establezca Relying Party ID = `auth.acme.com` - Corbado aloja el archivo de asociación para usted - Establezca el CNAME de `auth.acme.com` => `pro-XXX.frontendapi.cloud.corbado.io` ###### B1.2) Aplicación nativa y aplicación web - Establezca Relying Party ID = `auth.acme.com` - Corbado aloja el archivo de asociación para usted - Establezca el CNAME de `auth.acme.com` => `pro-XXX.frontendapi.cloud.corbado.io` (también necesario para que funcionen las cookies si utiliza la gestión de sesiones de Corbado) ##### B2) Dominio raíz como Relying Party ID ###### B2.1) Solo nativo - Establezca Relying Party ID = `acme.com` - Aloje el archivo de asociación usted mismo en su propio servidor en `acme.com/.well-known/` - No hay tareas pendientes de DNS para usted ###### B2.2) Aplicación nativa y aplicación web - Establezca Relying Party ID = `acme.com` - Aloje el archivo de asociación usted mismo en su propio servidor en `acme.com/.well-known/` - Si utiliza la gestión de sesiones de Corbado, debe establecer el CNAME de `auth.acme.com` => `pro-XXX.frontendapi.cloud.corbado.io` para que funcionen las cookies (este CNAME no es necesario para el Relying Party ID únicamente para la gestión de sesiones) El siguiente árbol de decisión resume todas las rutas de configuración. ## 10. Conclusión El Relying Party ID es una piedra [angular](https://www.corbado.com/blog/angular-passkeys) de WebAuthn y de la autenticación basada en claves de acceso, y proporciona una gran resistencia frente al phishing. Configurar correctamente el entorno, comprender las complejidades de la coincidencia de dominios y garantizar una implementación correcta para las aplicaciones nativas es fundamental. En esta publicación de blog, le hemos mostrado cómo configurarlos correctamente y cómo manejar diferentes errores. Una vez que su configuración de rpID sea sólida, concéntrese en optimizar sus flujos de creación e inicio de sesión con claves de acceso para impulsar una adopción real. Si tiene más preguntas o necesita ayuda, no dude en [contactarnos](https://bit.ly/passkeys-community). ## Preguntas frecuentes ### ¿Cómo previene el Relying Party ID el phishing en la autenticación con claves de acceso? El autenticador compara el origen real del navegador con el Relying Party ID almacenado en la clave de acceso. Si un atacante aloja un sitio falso en un dominio diferente, la discrepancia de origen hace que la autenticación falle automáticamente, incluso si el desafío falsificado afirma tener un RP ID legítimo. Esta vinculación significa que una clave de acceso registrada en paypal.com no se puede utilizar en un dominio similar como paybal.com. ### ¿Qué sucede si cambio mi WebAuthn Relying Party ID después de que los usuarios ya hayan registrado claves de acceso? Cambiar el RP ID invalida todas las claves de acceso existentes porque el RP ID almacenado en cada credencial ya no coincidirá con el nuevo valor. Las únicas excepciones son cuando el nuevo RP ID es un subdominio del antiguo o cuando se configuran Related Origin Requests a través de `.well-known/webauthn`. Elija el dominio raíz como RP ID desde el principio para evitar este problema irreversible. ### ¿Por qué mi clave de acceso de iOS no funciona inmediatamente después de implementar el archivo apple-app-site-association? iOS no recupera el archivo apple-app-site-association directamente desde su servidor. Utiliza la CDN de Apple, que puede tardar hasta 24 horas en almacenar en caché un archivo recién implementado o actualizado. Durante el desarrollo, agregue `?mode=developer` al Relying Party ID para omitir por completo el almacenamiento en caché. ### ¿Debo usar un subdominio o un dominio raíz como mi Relying Party ID para las claves de acceso? Se recomienda usar el dominio raíz (p. ej., acme.com) porque las claves de acceso creadas en cualquier subdominio pueden autenticarse en todos los subdominios de esa raíz. Un RP ID de subdominio restringe el uso de la clave de acceso a ese subdominio y sus elementos secundarios, lo que puede interrumpir los flujos entre subdominios más adelante. Si tiene varios dominios raíz, como acme.com y acme.co.uk, configure Related Origin Requests a través de `.well-known/webauthn` para permitir la reutilización de claves de acceso en ellos.