Tipos de aplicaciones para la Plataforma de identidad de Microsoft

La Plataforma de identidad de Microsoft admite la autenticación de diversas arquitecturas de aplicaciones modernas, todas ellas basadas en los protocolos estándar del sector OAuth 2.0 u OpenID Connect. En este artículo se describen los tipos de aplicaciones que puede compilar mediante la Plataforma de identidad de Microsoft, independientemente de su plataforma o idioma preferidos. La información está diseñada para ayudarlo a entender los escenarios de alto nivel antes de empezar a trabajar con el código en los escenarios de las aplicaciones.

Conceptos básicos

Debe registrar cada aplicación que usa la Plataforma de identidad de Microsoft en Registros de aplicaciones del centro de administración Microsoft Entra. El proceso de registro de la aplicación recopila y asigna algunos valores a la aplicación:

• Un identificador de la aplicación (cliente) que identifica la aplicación de manera única.
• Un URI de redirección que puede usarse para dirigir las respuestas de nuevo a la aplicación
• Algunos otros valores específicos para el escenario, como los tipos de cuentas compatibles.

Para más información, aprenda a registrar una aplicación.

Una vez que la aplicación se registra, se comunica con la Plataforma de identidad de Microsoft mediante el envío de solicitudes al punto de conexión. Proporcionamos bibliotecas y marcos de código abierto que controlan los detalles de estas solicitudes. También tiene la opción de implementar la lógica de autenticación por su cuenta mediante la creación de solicitudes a estos puntos de conexión:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token

Los tipos de aplicación compatibles con la Plataforma de identidad de Microsoft son;

• Aplicación de página única (SPA)
• Aplicación web
• API Web
• Aplicaciones móviles y nativas
• Servicio, demonio, script

Aplicaciones de una sola página

Muchas aplicaciones modernas tienen un front-end de aplicación de página única (SPA) escrito principalmente en JavaScript, a menudo con un marco como Angular, React o Vue. La plataforma de identidad de Microsoft admite estas aplicaciones utilizando el protocolo OpenID Connect para la autenticación y uno de los dos tipos de concesiones de autorización definidos por OAuth 2.0. Los tipos de concesión admitidos son el flujo de concesión implícita de OAuth 2.0 o el más reciente código de autorización de OAuth 2.0 y el flujo de PKCE (consulte a continuación).

En el diagrama de flujo se muestra el flujo de la concesión de código de autorización de OAuth 2.0 (con los detalles sobre PKCE omitidos), donde la aplicación recibe un código del punto de conexión authorize de la plataforma de identidad de Microsoft y lo canjea por un token de acceso y un token de actualización mediante solicitudes web entre sitios. En el caso de las SPA, el token de acceso es válido durante 1 hora y, una vez expirado, debe solicitar otro código mediante el token de actualización. Además del token de acceso, normalmente también se solicita un valor de id_token que representa el usuario que ha iniciado sesión en la aplicación cliente a través del mismo flujo o de una solicitud OpenID Connect independiente (no se muestra aquí).

Para ver esto en acción, vaya al Inicio rápido: Inicio de sesión de usuarios en una aplicación de página única (SPA) y llamada a Microsoft Graph API mediante JavaScript.

Flujo de código de autorización frente a flujo implícito

El flujo de código de autorización de OAuth 2.0 es ahora la manera recomendada de compilar SPA para garantizar la compatibilidad de la aplicación en Safari y otros exploradores que tienen en cuenta la privacidad. Después de la eliminación de cookies de terceros y mayor atención, no se recomienda el uso continuado del flujo implícito.

Aplicaciones web

En las aplicaciones web (. NET, PHP, Java, Ruby, Python, Node) a las que el usuario accede a través de un explorador, puede usar OpenID Connect para el inicio de sesión de usuario. En OpenID Connect, la aplicación web recibe un identificador de token. Un token de id. es un token de seguridad que comprueba la identidad del usuario y proporciona información sobre el usuario en forma de notificaciones:

// Partial raw ID token
abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9...

// Partial content of a decoded ID token
{
    "name": "Casey Jensen",
    "email": "casey.jensen@onmicrosoft.com",
    "oid": "ab12cd34-effe-5678-9012-abcdef012345"
    ...
}

Hay más detalles sobre los diferentes tipos de token que se usan en la Plataforma de identidad de Microsoft en la referencia Token de acceso y en la referencia id_token.

En las aplicaciones de servidor web, el flujo de autenticación de inicio de sesión realiza estos pasos de alto nivel:

Puede confirmar la identidad del usuario mediante la validación del token de id. con una clave de firma pública recibida por la Plataforma de identidad de Microsoft. Se establece una cookie de sesión, que puede usarse para identificar al usuario en las sucesivas solicitudes de página.

Para más información, cree una aplicación web de ASP.NET Core que inicie sesión a los usuarios en las siguientes series de tutoriales de varias partes

Además del inicio de sesión sencillo, una aplicación web de servidor podría tener la necesidad de acceder a otro servicio web, como una API Transferencia de estado representacional (REST). En este caso, la aplicación de servidor web participa en un flujo combinado de OpenID Connect y OAuth 2.0, mediante el flujo de código de autorización de OAuth 2.0. Para obtener más información sobre este escenario, consulte nuestro ejemplo de código.

API web

Puede usar la Plataforma de identidad de Microsoft para proteger los servicios web, como la API web RESTful de la aplicación. Las API web se pueden implementar en numerosas plataformas y lenguajes. También se pueden implementar mediante desencadenadores HTTP en Azure Functions. En lugar de tokens de identificador y cookies de sesión, una API web usa un token de acceso de OAuth 2.0 para proteger sus datos y para autenticar las solicitudes entrantes.

El autor de la llamada de una API web anexa un token de acceso en el encabezado de autorización de una solicitud HTTP, como esta:

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9...
Accept: application/json
...

La API web usa el token de acceso para comprobar la identidad del autor de la llamada de API y extraer información sobre este de las notificaciones que se codifican en dicho token. Hay más detalles sobre los diferentes tipos de token que se usan en la Plataforma de identidad de Microsoft en la referencia Token de acceso y en la referencia id_token.

Una API web puede ofrecer a los usuarios la capacidad para administrar la participación o no participación en ciertas funcionalidades o datos mediante la exposición de permisos, conocidos también como ámbitos. Para que una aplicación de llamada adquiera permiso para un ámbito, el usuario debe consentir el ámbito durante un flujo. La Plataforma de identidad de Microsoft solicita al usuario permiso y luego registra los permisos en todos los tokens de acceso que recibe la API web. La API web valida los tokens de acceso que recibe en cada llamada y realiza comprobaciones de autorización.

Una API web puede recibir tokens de acceso de todos los tipos de aplicaciones, incluidas las aplicaciones de servidor web, aplicaciones móviles y de escritorio, aplicaciones de página única, demonios del lado servidor e incluso otras API web. El flujo general de una API web se parece a este:

Para aprender a proteger una API web con tokens de acceso de OAuth2, consulte los ejemplos de código de API web del tutorial de API web protegida.

En muchos casos, las API web también tienen que realizar solicitudes salientes a otras API web de bajada protegidas por la Plataforma de identidad de Microsoft. Para ello, las API web pueden aprovechar las ventajas del flujo con derechos delegados (OBO), que permite a la API web intercambiar un token de acceso entrante por otro token de acceso que se usará en las solicitudes salientes. Para más información, consulte Plataforma de identidad de Microsoft y flujo con derechos delegados de OAuth 2.0.

Aplicaciones móviles y nativas

Las aplicaciones instaladas en un dispositivo, como las aplicaciones móviles y de escritorio, suelen necesitar el acceso a servicios back-end o a las API web que almacenan datos y realizan funciones en nombre del usuario. Estas aplicaciones pueden agregar el inicio de sesión y la autorización a los servicios back-end mediante el flujo de código de autorización de OAuth 2.0.

En este flujo, la aplicación recibe un código de autorización de la Plataforma de identidad de Microsoft cuando el usuario inicia sesión. El código de autorización representa el permiso de la aplicación para llamar a servicios de back-end en nombre del usuario que inició la sesión. La aplicación podrá intercambiar el código de autorización en segundo plano para un token de acceso de OAuth 2.0 y un token de actualización. La aplicación puede usar el token de acceso para autenticar las API web en las solicitudes HTTP y utilizar el token de actualización para obtener nuevos tokens de acceso cuando expiren los antiguos.

Nota:

Si la aplicación usa la vista web predeterminada del sistema, consulte la información sobre la funcionalidad "Confirmar mi inicio de sesión" y el código de error AADSTS50199 en Códigos de error de autenticación y autorización de Microsoft Entra.

Servidor, demonios y scripts

Las aplicaciones que contienen procesos de larga duración o que funcionan sin la interacción con un usuario también necesitan un modo de acceder a recursos protegidos, como las API web. Estas aplicaciones pueden autenticarse y obtener tokens mediante la identidad de la aplicación, en lugar de una identidad delegada del usuario, con el flujo de credenciales de cliente de OAuth 2.0. Puede demostrar la identidad de la aplicación mediante un certificado o secreto de cliente. Para obtener más información, vea aplicación de consola de demonio de .NET mediante la plataforma de identidad de Microsoft.

En este flujo, la aplicación interactúa directamente con el punto de conexión /token para obtener acceso:

Para compilar una aplicación demonio, consulte la documentación de credenciales de cliente en nuestra sección de introducción o pruebe una aplicación de ejemplo de .NET.

Consulte también

Ahora que está familiarizado con los tipos de aplicaciones compatibles con la Plataforma de identidad de Microsoft, obtenga más información sobre OAuth 2.0 y OpenID Connect para comprender los componentes de protocolo que usan los distintos escenarios.