WebAuthn Relying Party ID (rpID) y claves de acceso: dominios y aplicaciones nativas

La autenticación mediante claves de acceso se está convirtiendo rápidamente en la norma a medida que gigantes tecnológicos como TikTok, GitHub, WhatsApp, X (Twitter), LinkedIn y Amazon las implementan o ya lo han hecho. Es evidente que el mundo tecnológico está reconociendo la importancia de una autenticación sencilla y segura.

Más allá de la experiencia de usuario fluida al autenticarse con Face ID, Touch ID o Windows Hello, las claves de acceso ofrecen una seguridad incomparable en comparación con los métodos de autenticación tradicionales como las contraseñas. Una de las características más destacadas es su fuerte resistencia al phishing.

Hoja de referencia de Passkeys. Guías prácticas, patrones de despliegue y KPIs para programas de passkeys.

Obtener cheat sheet

Prueba passkeys en una demo en vivo.

Probar passkeys

Un ataque de 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 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 (¡un proveedor de autenticación!) o Retool han sido víctimas de ataques de spear-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 sólidas.

Por el contrario, si utiliza una clave de acceso y el sitio es falso, su autenticación fallará. Esto se debe a que las claves de acceso están vinculadas a los dominios para los que fueron creadas a través del Relying Party ID.

Este mecanismo está integrado en WebAuthn, el estándar web subyacente a las claves de acceso para la autenticación sin contraseña. 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 para un servicio en línea (el Relying Party) a través de una aplicación web 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), al que pertenece la aplicación web o nativa, coincide con el Relying Party ID almacenado en la clave de acceso.

A continuación, veremos en detalle cómo funciona este proceso de coincidencia de dominios y cómo se protegen las aplicaciones nativas en particular.

El Relying Party ID 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 a continuación). Es un componente crucial de la especificación WebAuthn, en la que puede profundizar aquí. 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í). 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:

A continuación, puede ver el objeto PublicKeyCredentialCreationOptions analizado:

{
    "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 que es un sitio web falso que intenta robar sus credenciales de PayPal para iniciar sesión en su nombre y enviar dinero a la cuenta del atacante. Este sitio web falso de PayPal 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:<SHA256_fingerprint>. 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). 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.

Forma parte de nuestra comunidad de passkeys para recibir novedades y soporte.

Unirse

Para implementar claves de acceso en una aplicación nativa, un desarrollador puede decidir entre agregarlas a través de un WebView o de forma nativa. Examinemos los beneficios y desventajas de ambos enfoques a continuación.

El uso de un WebView* para integrar claves de acceso significa integrar un navegador web dentro de la aplicación nativa 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 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.

Consulta cuántas personas usan passkeys realmente.

Ver datos de adopción

La integración nativa implica la creación de la funcionalidad de la clave de acceso directamente en la aplicación de iOS o 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. También permite un mejor rendimiento y una apariencia más coherente. Desde el punto de vista de la seguridad, 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). 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.

Consulta cuántas personas usan passkeys realmente.

Ver datos de adopción

Las aplicaciones nativas (p. ej., aplicaciones de iOS o 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).

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.

{
    "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://<Relying Party ID>/.well-known/apple-app-site-association).

Vea un ejemplo en vivo aquí.

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.

[
    {
        "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í.

Para que funcionen las aplicaciones de Android, el archivo assetlinks.json debe almacenarse en el directorio /.well-known de los Relying Party IDs https://<Relying Party ID>/.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.

Experimenta con flujos de passkeys en Passkeys Debugger.

Probar gratis

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 dentro de la aplicación de iOS.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

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í.

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://<Relying Party ID>./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 dentro de la aplicación de Android.

El siguiente diagrama compara estos procesos de establecimiento de confianza lado a lado.

Suscríbete a nuestro Substack de passkeys para recibir las últimas noticias.

Suscribirse

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.

Para Flutter, se aplica la regla respectiva de Android o iOS. La única configuración específica de Flutter es el registro de los archivos de asociación, donde debe agregar:

• Para Android: flutter_deeplinking_enabled en AndroidManifest.xml
• Para iOS: FlutterDeepLinkingEnabled true en Info.plist

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.

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.

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.

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.

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.

Forma parte de nuestra comunidad de passkeys para recibir novedades y soporte.

Unirse

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.

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.

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 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 y Android.

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).

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.

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).

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?

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.

• 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

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)

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)

• 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

• 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)

• Establezca Relying Party ID = acme.com
• Aloje el archivo de asociación usted mismo en su propio servidor en acme.com/.well-known/<archivo de asociación>
• No hay tareas pendientes de DNS para usted

• Establezca Relying Party ID = acme.com
• Aloje el archivo de asociación usted mismo en su propio servidor en acme.com/.well-known/<archivo de asociación>
• 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.

El Relying Party ID es una piedra angular 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.

Acerca de Corbado

Corbado es la Passkey Intelligence Platform para equipos de CIAM que gestionan autenticación de consumidores a gran escala. Te ayudamos a ver lo que los logs de tu IDP y las herramientas de analytics genéricas no muestran: qué dispositivos, versiones de SO, navegadores y gestores de credenciales soportan passkeys, por qué los registros no se convierten en inicios de sesión, dónde falla el flujo de WebAuthn y cuándo una actualización de SO o navegador rompe el login en silencio — todo sin reemplazar Okta, Auth0, Ping, Cognito o tu IDP propio. Dos productos: Corbado Observe aporta observabilidad para passkeys y cualquier otro método de login. Corbado Connect añade passkeys gestionados con analytics integrado (junto a tu IDP). VicRoads ejecuta passkeys para más de 5M de usuarios con Corbado (+80 % de activación de passkey). Habla con un experto en Passkeys →

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.

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.

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é.

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.