Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a: 
Inquilinos externos (más información)
la autenticación nativa de Microsoft Entra permite tener un control total sobre el diseño de la experiencia de inicio de sesión de la aplicación móvil y de escritorio. A diferencia de las soluciones basadas en explorador, la autenticación nativa permite crear pantallas de autenticación visualmente atractivas y perfectas para píxeles que se combinan perfectamente en la interfaz de la aplicación. Con este enfoque, puede personalizar completamente la interfaz de usuario, incluidos los elementos de diseño, la colocación del logotipo y el diseño, lo que garantiza un aspecto coherente y de marca.
El proceso de inicio de sesión de la aplicación estándar, que se basa en la autenticación delegada por el explorador, suele dar lugar a una transición perjudicial durante la autenticación. Los usuarios se redirigen temporalmente a un explorador del sistema para la autenticación, solo para volver a la aplicación una vez completado el inicio de sesión.
Aunque la autenticación delegada por explorador ofrece ventajas como vectores de ataque reducidos y compatibilidad con el inicio de sesión único (SSO), ofrece opciones limitadas de personalización de la interfaz de usuario.
Métodos de autenticación disponibles
Actualmente, la autenticación nativa admite un proveedor de identidades de cuenta local para dos métodos de autenticación:
- Correo electrónico con inicio de sesión mediante código de acceso de un solo uso (OTP).
- Inicio de sesión con correo electrónico y contraseña con soporte para el restablecimiento de contraseña mediante autoservicio (SSPR).
La autenticación nativa aún no admite proveedores de identidades federados, como identidades sociales o empresariales.
Cuándo usar la autenticación nativa
Cuando se trata de implementar la autenticación para aplicaciones móviles y de escritorio en el identificador externo, tiene dos opciones:
- Autenticación delegada por navegador alojada por Microsoft.
- Autenticación nativa con SDK completamente personalizado.
El enfoque que elija depende de los requisitos específicos de la aplicación. Aunque cada aplicación tiene necesidades de autenticación únicas, hay algunas consideraciones comunes que debe tener en cuenta. Tanto si elige la autenticación nativa como la autenticación delegada por el explorador, Microsoft Entra External ID admite ambas.
En la tabla siguiente se comparan los dos métodos de autenticación para ayudarle a decidir después la opción adecuada para la aplicación.
| Autenticación delegada por explorador | Autenticación nativa | |
|---|---|---|
| Experiencia de autenticación de usuario | Los usuarios son llevados a un navegador del sistema o a un navegador incrustado para autenticarse y luego ser redirigidos de nuevo a la aplicación cuando se complete el inicio de sesión. Este método se recomienda si el redireccionamiento no afecta negativamente a la experiencia del usuario final. | Los usuarios tienen un recorrido enriquecido, nativo de registro e inicio de sesión sin salir de la aplicación. |
| Experiencia de personalización | Las opciones de marca y personalización gestionadas están disponibles como una característica de fábrica. | Este enfoque centrado en la API ofrece un alto nivel de personalización, lo que proporciona una amplia flexibilidad en el diseño y la capacidad de crear interacciones y flujos personalizados. |
| Aplicabilidad | Adecuado para las aplicaciones de personal, B2B y B2C, se puede usar para aplicaciones nativas, aplicaciones de página única y aplicaciones web. | En el caso de las aplicaciones de primera entidad del cliente, cuando la misma entidad opera el servidor de autorización y la aplicación y el usuario las percibe como la misma entidad. |
| Esfuerzo de llamada en directo | Baja. Úselo directamente al sacarlo de la caja. | Alta. El desarrollador crea, posee y mantiene la experiencia de autenticación. |
| Esfuerzo de mantenimiento | Baja. | Alta. Para cada característica que Microsoft lance, necesita actualizar el SDK para utilizarla. |
| Security | La opción más segura. | La responsabilidad de seguridad se comparte con los desarrolladores y es necesario seguir los procedimientos recomendados. Es propenso a ataques de suplantación de identidad (phishing). |
| Lenguajes y marcos admitidos |
|
|
Disponibilidad de funcionalidades
En la tabla siguiente se muestra la disponibilidad de características para la autenticación nativa y delegada por el explorador.
| Autenticación delegada por explorador | Autenticación nativa | |
|---|---|---|
| Registro e inicio de sesión con código de acceso de un solo uso (OTP) de correo electrónico | ✔️ | ✔️ |
| Registro e inicio de sesión con correo electrónico y contraseña | ✔️ | ✔️ |
| Iniciar sesión con correo electrónico y contraseña puede usar el nombre de usuario (alias) y la contraseña | ✔️ | ✔️ |
| Restablecimiento de contraseña de autoservicio (SSPR) | ✔️ | ✔️ |
| Proveedor de notificaciones personalizado. | ✔️ | ✔️ |
| Autenticación multifactor con código de acceso de un solo uso (OTP) de correo electrónico | ✔️ | ✔️ |
| Autenticación multifactor con código de acceso de un solo uso (OTP) sms | ✔️ | ✔️ |
| Inicio de sesión del proveedor de identidades sociales (Apple, Facebook y Google con delegado del explorador) | ✔️ | ✔️ |
| Inicio de sesión único (SSO)1 | ✔️ | ✔️ |
1 La autenticación nativa solo admite SSO para vistas web incrustadas. El inicio de sesión único entre aplicaciones a través de exploradores del sistema no está disponible con la autenticación nativa. Para obtener información, consulte SSO.
Habilitación de la autenticación nativa
En primer lugar, revise las directrices sobre cuándo usar la autenticación nativa. A continuación, tenga una explicación interna con el propietario, el diseñador y el equipo de desarrollo de la aplicación para determinar si es necesaria la autenticación nativa.
Si el equipo determina que la autenticación nativa es necesaria para la aplicación, siga estos pasos para habilitar la autenticación nativa en el Microsoft Entra admin center:
- Inicie sesión en el Microsoft Entra admin center.
- Vaya a App registrations y seleccione el registro de aplicaciones para el que desea habilitar los flujos de autenticación nativa y cliente público.
- En Administrar, seleccione Autenticación.
- En Configuración avanzada, permita flujos de cliente públicos:
- En Habilitar los siguientes flujos móviles y de escritorio , seleccione Sí.
- En Habilitar autenticación nativa, seleccione Sí.
- Selecciona el botón Guardar.
Actualización del código de configuración
Después de habilitar las API de autenticación nativas en el Centro de administración, todavía debe actualizar el código de configuración de la aplicación para admitir flujos de autenticación nativos para Android o iOS/macOS. Para ello, debe agregar el campo tipo de desafío a la configuración. Los tipos de desafío son una lista de valores que usa la aplicación para notificar a Microsoft Entra sobre el método de autenticación que admite. Puede encontrar más información sobre los tipos de desafío de autenticación nativa en Tipos de desafío de autenticación nativa. Si la configuración no se actualiza para integrar componentes de autenticación nativos, los SDK de autenticación nativa y las API no se pueden usar.
Consideraciones de seguridad para la autenticación nativa
La autenticación nativa proporciona al equipo de desarrollo control total sobre la experiencia de autenticación. Con este control, es responsabilidad seguir los procedimientos recomendados de seguridad en la implementación de la aplicación, como el control seguro de tokens y la seguridad de transporte (HTTPS).
Inicio de sesión único (SSO)
La autenticación nativa admite el inicio de sesión único (SSO) para las vistas web insertadas. Esto permite a los usuarios iniciar sesión una vez a través de la interfaz de usuario de la aplicación nativa y, a continuación, acceder a los recursos web hospedados en una vista web insertada (por ejemplo, WKWebView en iOS o WebView en Android) sin encontrar un segundo mensaje de inicio de sesión.
La aplicación logra esto mediante la recuperación de un token de acceso mediante el SDK de autenticación nativa o la API de autenticación nativa e insertarlo en la solicitud HTTP de la vista web a través del Authorization encabezado . El recurso web valida el token y establece una sesión, lo que proporciona una transición sin problemas de la experiencia nativa al contenido web.
Para conocer los pasos de implementación, consulte Implementación del inicio de sesión único desde aplicaciones nativas a vistas web insertadas.
Note
El inicio de sesión único entre aplicaciones a través de exploradores del sistema no se admite con la autenticación nativa.
Uso de la autenticación nativa
Puede crear aplicaciones que usen la autenticación nativa mediante nuestras API de autenticación nativas o el SDK de Microsoft Authentication Library (MSAL) para Android, iOS, macOS y aplicaciones web. Siempre que sea posible, se recomienda usar MSAL para agregar autenticación nativa a las aplicaciones.
Para obtener más información sobre ejemplos y tutoriales de autenticación nativa, consulte la tabla siguiente:
| Lenguaje/ Plataforma |
Inicio rápido | Guía de compilación e integración |
|---|---|---|
| Android (Kotlin) | • Inicio de sesión de usuarios | • Inicio de sesión de usuarios |
| iOS (Swift) | • Inicio de sesión de usuarios | • Inicio de sesión de usuarios |
| macOS (Swift) | • Inicio de sesión de usuarios | • Inicio de sesión de usuarios |
| React (Next.js) | • Inicio rápido | • Tutoriales |
| Angular | • Inicio rápido | • Tutoriales |
Si planea crear una aplicación en un marco actualmente no compatible con MSAL, puede usar nuestra API de autenticación. Para más información, consulte Referencia de api de autenticación nativa.