Saltar al contenido principal
Las aplicaciones nativas usan el Flujo de código de autorización con PKCE de autenticación y emplean un redirect_uri para devolver el control a la aplicación después del inicio de sesión. Después de que el URI se carga en el navegador del dispositivo, la aplicación normalmente se abre automáticamente para que el usuario pueda continuar con el proceso. Históricamente, las aplicaciones móviles usaban esquemas de URI personalizados (por ejemplo, com.mycompany.myapp://oauth2redirect). Sin embargo, los esquemas de URI personalizados plantean un riesgo, ya que más de una aplicación en el dispositivo puede registrar el mismo esquema. Los sistemas operativos móviles no incluyen mecanismos integrados para garantizar que la aplicación que recibe la redirección sea la correcta. En este escenario, las aplicaciones maliciosas suplantan a las legítimas y reciben la respuesta de autorización (incluidos los tokens) sin que el usuario lo advierta, especialmente si el inicio de sesión único (SSO) está activo debido a la existencia de una sesión legítima previa, en cuyo caso no se requiere ninguna interacción adicional del usuario. PKCE realmente no ayuda en estos casos, ya que la aplicación maliciosa puede iniciar el flujo de login y esperar a recibir el callback sin que el usuario interactúe. Las aplicaciones que se ejecutan en una máquina local (por ejemplo, aplicaciones de escritorio o CLI) usan la interfaz de loopback para los callbacks (por ejemplo, http://127.0.0.1:51089/callback o http://localhost:61024/callback) y están expuestas a un riesgo similar. En este caso, otra aplicación en la misma máquina podría escuchar en el mismo puerto para interceptar la respuesta. Nos referimos tanto a los esquemas de URI personalizados como a los URI de loopback como URI de callback no verificables porque el Servidor de autorización no puede verificar la aplicación receptora en ninguno de los dos escenarios. Los sistemas operativos móviles modernos admiten las URI HTTPS verificadas, que le permiten asociar un dominio web que usted controla con su aplicación móvil. Las URI HTTPS verificadas se conocen como:
  • Universal Links en iOS
  • App Links en Android
Las URI HTTPS verificadas garantizan que solo su aplicación gestione la URL de devolución de llamada asociada y protegen contra el acceso no autorizado a datos confidenciales de autenticación.
Auth0 recomienda encarecidamente usar URI HTTPS verificadas como URI de redirección para todas las aplicaciones nativas.
Auth0 no puede verificar la legitimidad de la aplicación que recibe los resultados de la transacción de autenticación si:
  • Su aplicación no puede admitir URI HTTPS declarados debido a la compatibilidad requerida con versiones anteriores de sistemas operativos móviles
  • Su aplicación es una aplicación de escritorio o de CLI
Tal como se define en la especificación OAuth2 for Native Apps, Auth0 proporciona un mecanismo para mostrar una pantalla de confirmación al usuario. Los usuarios confirman que la aplicación que recibe el resultado de la autenticación es la que pretendían usar. Cuando se utiliza un URI de callback no verificable, se solicita al usuario que verifique la aplicación en cada transacción de autenticación. La pantalla de confirmación se muestra cuando:
  1. El redirect_uri presente en la solicitud utiliza un URI no verificable (es decir, un esquema de URI personalizado o un URI de loopback).
  2. No se le ha mostrado al usuario ninguna otra pantalla en la transacción de inicio de sesión actual (por ejemplo, cuando se muestra una pantalla de consent para aplicaciones de terceros, o cuando se requiere MFA).
En estos casos, se presenta una pantalla de confirmación al usuario final.
Medidas contra la suplantación de aplicaciones: pantalla de confirmación
La pantalla de confirmación no se muestra en flujos heredados no conformes a OIDC. Para obtener información sobre cómo aplicar mayor protección a sus inquilinos y aplicaciones, consulte Adoptar la autenticación conforme a OIDC.

​
Personalización de la pantalla

La pantalla de confirmación usa la marca y la configuración personalizadas que definiste para las pantallas de consent existentes que se usan en aplicaciones de terceros. Para obtener más información, consulta la sección Prompts de Personalizar las plantillas de página de Universal Login.
Auth0 recomienda encarecidamente no desactivar esta protección en producción. Las aplicaciones maliciosas en el dispositivo podrían solicitar id_tokens y access_tokens sin ninguna interacción del usuario ni ninguna otra indicación de que haya ocurrido algo.
Puedes configurar la pantalla de confirmación como una configuración global del inquilino o a nivel de aplicación. La configuración a nivel de aplicación tiene prioridad sobre la configuración global a nivel de inquilino. A nivel de aplicación
  1. Ve a Auth0 Dashboard > Applications > configuración de la aplicación > Advanced > OAuth.
  2. Desplázate hasta la configuración Non-Verifiable Callback URI End-User Confirmation.
  3. Activa el interruptor para habilitar la pantalla o desactívalo para deshabilitarla.
Auth0 Dashboard>Settings>Advanced
Global
  1. Ve a Auth0 Dashboard > Settings > Advanced.
  2. Busca la configuración Non-Verifiable Callback URI End-User Confirmation.
  3. Activa el interruptor para habilitar la pantalla.
Auth0 Dashboard>Tenant Settings>Advanced>Skip Custom URI toggle