Tipos de aplicaciones y flujos de autenticación de la plataforma de identidad de Microsoft
La Plataforma de identidad de Microsoft admite la autenticación para diferentes tipos de arquitecturas de aplicación modernas. Todas ellas se basan en los protocolos estándar del sector OAuth 2.0 y OpenID Connect. Con las bibliotecas de autenticación de la plataforma de identidad de Microsoft, las aplicaciones autentican las identidades y adquieren tokens para acceder a API protegidas.
En este artículo se describen los flujos de autenticación y los escenarios de aplicaciones en los que se usan.
Categorías de aplicaciones
Los tokens de seguridad se pueden adquirir a partir de varios tipos de aplicaciones, entre las que se incluyen:
- Aplicaciones web
- Aplicaciones móviles
- Aplicaciones de escritorio
- API web
Los tokens también pueden ser adquiridos por aplicaciones que se ejecutan en dispositivos sin explorador o en Internet de las cosas (IoT).
En las secciones siguientes se describen las categorías de aplicaciones.
Recursos protegidos frente a aplicaciones cliente
Los escenarios de autenticación implican dos actividades:
- Adquisición de tokens de seguridad para una API web protegida: Se recomienda usar la biblioteca de autenticación de Microsoft (MSAL), desarrollada por Microsoft y con el soporte técnico de Microsoft.
- Protección de una API web o una aplicación web: un reto a la hora de proteger estos recursos es validar el token de seguridad. En algunas plataformas, Microsoft ofrece bibliotecas de middleware.
Con usuarios o sin usuarios
La mayoría de los escenarios de autenticación adquieren tokens en nombre de un usuario con la sesión iniciada.
Sin embargo, también hay aplicaciones de demonio. En estos escenarios, las aplicaciones adquieren los tokens en su propio nombre, sin usuario.
Aplicaciones cliente públicas y confidenciales, de página única
Hay varios tipos de aplicaciones que pueden adquirir tokens de seguridad. Estas aplicaciones tienden a dividirse en las tres categorías siguientes. Cada se usa con diferentes bibliotecas y objetos.
Aplicaciones de página única: también conocidas como SPA, son aplicaciones web en las que los tokens son adquiridos por una aplicación de JavaScript o TypeScript que se ejecuta en el explorador. Muchas aplicaciones modernas tienen una aplicación de página única en el front-end, que está escrita principalmente en JavaScript. A menudo, la aplicación usa un marco como Angular, React o Vue. MSAL.js es la única biblioteca de autenticación de Microsoft que admite aplicaciones de página única.
Aplicaciones cliente públicas: las aplicaciones de esta categoría, como los tipos siguientes, siempre inician la sesión de los usuarios:
- Aplicaciones de escritorio que llaman a API web en nombre de los usuarios que han iniciado sesión
- Aplicaciones móviles
- Aplicaciones que se ejecutan en dispositivos sin explorador, como las que se ejecutan en IoT
Aplicaciones cliente confidenciales: las aplicaciones de esta categoría incluyen:
- Aplicaciones web que llaman a una API web
- API web que llaman a una API web
- Aplicaciones de demonio, incluso cuando se implementan como servicio de consola, como un demonio de Linux o un servicio de Windows
Inicio de sesión de la audiencia
los flujos de autenticación disponibles difieren en función de la audiencia de inicio de sesión. Algunos flujos solo están disponibles para las cuentas profesionales o educativas. Otros están disponibles para las cuentas profesionales o educativas y para las cuentas Microsoft personales.
Para más información, consulte Tipos de cuenta admitidos.
Tipos de aplicación
La Plataforma de identidad de Microsoft admite la autenticación en estas arquitecturas de aplicaciones:
- Aplicaciones de una sola página
- Aplicaciones web
- API web
- Aplicaciones móviles
- Aplicaciones nativas
- Aplicaciones de demonio
- Aplicaciones de servidor
Las aplicaciones usan los distintos flujos de autenticación para iniciar la sesión de los usuarios y obtener tokens para llamar a API protegidas.
Aplicación de una sola página
Muchas aplicaciones web modernas se compilan como aplicaciones de página única del lado cliente. Estas aplicaciones usan JavaScript o un marco de trabajo como Angular, Vue y React. Estas aplicaciones se ejecutan en un explorador web.
Las aplicaciones de página única difieren de las aplicaciones web tradicionales del lado servidor en las características de autenticación. Con la plataforma de identidad de Microsoft las aplicaciones de página única pueden iniciar la sesión de los usuarios y obtengan tokens para acceder a los servicios de back-end o a las API web. La Plataforma de identidad de Microsoft ofrece dos tipos de concesión para las aplicaciones JavaScript:
MSAL.js (2.x) | MSAL.js (1.x) |
---|---|
Aplicación web que inicia la sesión de un usuario
Para ayudar a proteger una aplicación web que inicia la sesión de un usuario:
Si se está desarrollando en .NET, se usa ASP.NET o ASP.NET Core con el middleware ASP.NET OpenID Connect. La protección de un recurso conlleva la validación del token de seguridad, que se realiza con las extensiones de IdentityModel para .NET y no con las bibliotecas MSAL.
Si se desarrolla en Node.js, se usa Nodo MSAL.
Para más información, consulte Aplicación web que permite iniciar sesión a los usuarios.
Aplicación web que inicia la sesión de un usuario y llama a una API web en nombre del usuario
Para llamar a una API web desde una aplicación web en nombre de un usuario, use el flujo de código de autorización y almacene los tokens adquiridos en la caché de tokens. Cuando sea necesario, MSAL actualiza los tokens y el controlador adquiere los tokens de la memoria caché de forma silenciosa.
Para más información, consulte Aplicación web que llama a las API web.
Aplicación de escritorio que llama a una API web en nombre de un usuario que ha iniciado sesión
Para que una aplicación de escritorio llame a una API web que inicia la sesión de los usuarios, use los métodos de adquisición de tokens interactivos de MSAL. Estos métodos interactivos permiten controlar la experiencia de inicio de sesión en la interfaz de usuario. MSAL usa un explorador web para esta interacción.
Existe otra posibilidad para las aplicaciones alojadas en Windows en ordenadores unidos a un dominio de Windows o mediante Microsoft Entra ID. Estas aplicaciones pueden adquirir un token de forma silenciosa con la autenticación integrada de Windows.
Las aplicaciones que se ejecutan en un dispositivo sin explorador podrán seguir llamando a una API en nombre de un usuario. Para realizar la autenticación, el usuario debe iniciar sesión en otro dispositivo que tenga un explorador web. En este escenario es necesario usar el flujo de código del dispositivo.
Aunque no se recomienda usarlo, el flujo de nombre de usuario y contraseña está disponible en las aplicaciones cliente públicas. Este flujo sigue siendo necesario en algunos escenarios, como DevOps.
El uso del flujo de nombre de usuario y contraseña restringe las aplicaciones. Por ejemplo, las aplicaciones no pueden dar de alta a un usuario que necesite utilizar la autenticación multifactor o la herramienta de acceso condicional de Microsoft Entra ID. Las aplicaciones tampoco se benefician del inicio de sesión único. La autenticación mediante el flujo de nombre de usuario y contraseña va en contra de los principios de la autenticación moderna y solo se proporciona por motivos de herencia.
En aplicaciones de escritorio, si quiere que la caché de tokens persista, puede personalizar la serialización de la caché de tokens. Con la implementación de la serialización de la caché de tokens dual, puede usar cachés de tokens compatibles con versiones anteriores y posteriores.
Para más información, consulte Aplicación de escritorio que llama a las API web.
Aplicación móvil que llama a una API web en nombre de un usuario interactivo
De forma parecida a una aplicación de escritorio, una aplicación móvil llama a los métodos interactivos de adquisición de tokens de MSAL para adquirir un token para llamar a una API web.
MSAL iOS y MSAL Android usan el explorador web del sistema de forma predeterminada. Pero puede dirigirlos para que usen la vista web insertada en su lugar. Existen algunas características específicas que dependen de la plataforma móvil: Plataforma universal de Windows (UWP), iOS o Android.
Algunos escenarios, como los que implican el acceso condicional relacionado con un identificador de dispositivo o una inscripción de dispositivo, requieren que se instale un agente en el dispositivo. Algunos ejemplos de agentes son Portal de empresa de Microsoft en Android y Microsoft Authenticator en Android e iOS.
Para más información, consulte Aplicación móvil que llama a las API web.
Nota:
Una aplicación móvil que usa MSAL iOS o MSAL Android puede tener aplicadas directivas de protección de aplicaciones. Por ejemplo, las directivas pueden impedir que un usuario copie texto protegido. Intune administra la aplicación móvil y reconoce este servicio como una aplicación administrada. Para más información, consulte Introducción al SDK para aplicaciones de Microsoft Intune.
Intune App SDK es independiente de las bibliotecas MSAL e interactúa con Microsoft Entra ID por sí solo.
API web protegida
Puede usar el punto de conexión de la Plataforma de identidad de Microsoft para proteger servicios web como la API RESTful de la aplicación. Se llama a una API web protegida mediante un token de acceso. El token ayuda a proteger los datos de la API y a autenticar las solicitudes entrantes. El llamador de una API web anexa un token de acceso al encabezado de autorización de una solicitud HTTP.
Si quiere proteger su API web de ASP.NET o ASP.NET Core, valide el token de acceso. Para la validación se usa el middleware JWT de ASP.NET. Esta validación se realiza con la biblioteca de extensiones IdentityModel para .NET, no con MSAL.NET.
Para más información, consulte API web protegida.
API web que llama a otra API web en nombre de un usuario
Para que la API web protegida llame a otra API web en nombre de un usuario, la aplicación debe adquirir un token para la API web de bajada. Estas llamadas a veces se denominan llamadas de servicio a servicio. Las API web que llaman a otras API web tienen que proporcionar serialización de caché personalizada.
Para más información, consulte API web que llama a las API web.
Aplicación de demonio que llama a una API web en nombre del demonio
Las aplicaciones que contienen procesos de larga duración o que funcionan sin la interacción de usuario también necesitan un modo de acceder a API web protegidas. Estas aplicaciones pueden autenticarse y obtener tokens mediante la identidad de la aplicación. La aplicación demuestra su identidad mediante un certificado o secreto de cliente.
Puede escribir estas aplicaciones de demonio que adquieren un token para la aplicación que realiza la llamada con los métodos de adquisición de credenciales de cliente de MSAL. Estos métodos requieren un secreto de cliente que se agrega al registro de la aplicación en Microsoft Entra ID. A continuación, la aplicación comparte el secreto con el demonio al que ha llamado. Ejemplos de estos secretos son las contraseñas de aplicación, la aserción de certificado y la aserción de cliente.
Para más información, consulte Aplicación de demonio que llama a las API web.
Escenarios y flujos de autenticación compatibles
Puede usar flujos de autenticación para implementar los escenarios de aplicaciones que solicitan tokens. No hay ninguna asignación individual entre los escenarios de aplicaciones y los flujos de autenticación.
Los escenarios que implican la adquisición de tokens también se asignan a flujos de autenticación de OAuth 2.0. Para más información, consulte Protocolos OAuth 2.0 y OpenID Connect en la Plataforma de identidad de Microsoft.
Escenario | Tutorial detallado de escenarios | Flujo y concesión de OAuth 2.0 | Público |
---|---|---|---|
Aplicación de una sola página | Código de autorización con PKCE | Cuentas profesionales o educativas, cuentas personales y Azure Active Directory B2C (Azure AD B2C) | |
Aplicación de una sola página | Implícito | Cuentas profesionales o educativas, cuentas personales y Azure Active Directory B2C (Azure AD B2C) | |
Aplicación web que permite iniciar sesión a los usuarios | Código de autorización | Cuentas profesionales o educativas, cuentas personales y Azure AD B2C | |
Aplicación web que llama a las API web | Código de autorización | Cuentas profesionales o educativas, cuentas personales y Azure AD B2C | |
Aplicación de escritorio que llama a las API web | De forma interactiva mediante un código de autorización con PKCE | Cuentas profesionales o educativas, cuentas personales y Azure AD B2C | |
Autenticación integrada de Windows | Cuentas profesionales o educativas | ||
Contraseña del propietario del recurso | Cuentas profesionales o educativas y Azure AD B2C | ||
Aplicación sin explorador | Código del dispositivo | Cuentas profesionales o educativas, cuentas personales, pero no Azure AD B2C | |
Aplicación móvil que llama a las API web | De forma interactiva mediante un código de autorización con PKCE | Cuentas profesionales o educativas, cuentas personales y Azure AD B2C | |
Contraseña del propietario del recurso | Cuentas profesionales o educativas y Azure AD B2C | ||
Aplicación de demonio que llama a las API web | Credenciales de cliente | Permisos solo para aplicaciones que no tienen usuario y solo se utilizan en organizaciones Microsoft Entra | |
API web que llama a API web | En nombre de | Cuentas profesionales o educativas y cuentas personales |
Escenarios, plataformas y lenguajes compatibles
Las bibliotecas de autenticación de Microsoft admiten varias plataformas:
- .NET
- .NET Framework
- Java
- JavaScript
- macOS
- Android nativo
- iOS nativo
- Node.js
- Python
- Windows 10/UWP
También puede usar varios lenguajes para compilar las aplicaciones.
En la columna Windows de la tabla siguiente, cada vez que se menciona .NET, también es posible .NET Framework. El último se omite para evitar la acumulación en la tabla.
Escenario | Windows | Linux | Mac | iOS | Android |
---|---|---|---|---|---|
Aplicación de una sola página |
MSAL.js |
MSAL.js |
MSAL.js |
MSAL.js |
|
Aplicación de una sola página |
MSAL.js |
MSAL.js |
MSAL.js |
MSAL.js |
|
Aplicación web que permite iniciar sesión a los usuarios |
ASP.NET Core MSAL Node |
ASP.NET Core MSAL Node |
ASP.NET Core MSAL Node |
||
Aplicación web que llama a las API web |
ASP.NET Core + MSAL.NET Java de MSAL Flask + MSAL Python MSAL Node |
ASP.NET Core + MSAL.NET Java de MSAL Flask + MSAL Python MSAL Node |
ASP.NET Core + MSAL.NET Java de MSAL Flask + MSAL Python MSAL Node |
||
Aplicación de escritorio que llama a las API web |
Java de MSAL MSAL Python MSAL Node |
Java de MSAL MSAL Python MSAL Node |
Java de MSAL MSAL Python MSAL Node |
||
Aplicación móvil que llama a las API web |
|||||
Aplicación de demonio |
Java de MSAL MSAL Python MSAL Node |
Java de MSAL MSAL Python MSAL Node |
Java de MSAL MSAL Python MSAL Node |
||
API web que llama a API web |
ASP.NET Core + MSAL.NET Java de MSAL MSAL Python MSAL Node |
ASP.NET Core + MSAL.NET Java de MSAL MSAL Python MSAL Node |
ASP.NET Core + MSAL.NET Java de MSAL MSAL Python MSAL Node |
Para más información, consulte Bibliotecas de autenticación de la Plataforma de identidad de Microsoft.
Pasos siguientes
Para obtener más información acerca de la autenticación, vea:
Comentarios
https://aka.ms/ContentUserFeedback.
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea:Enviar y ver comentarios de