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 de Azure Portal. 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

Aplicaciones de una página (JavaScript)

Muchas aplicaciones modernas tienen un front-end de aplicación de página única escrito principalmente en JavaScript, a menudo con un marco como Angular, React o Vue. La Plataforma de identidad de Microsoft es compatible con estas aplicaciones mediante el protocolo OpenID Connect para la autenticación y flujo de concesión implícita de OAuth 2.0 o flujo de código de autorización de OAuth 2.0 más PKCE, el más reciente, para la autorización (consulte a continuación).

En el diagrama de flujo siguiente se muestra 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. El token de acceso expira cada 24 horas, y la aplicación debe solicitar otro código con 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í).

Diagrama que muestra el flujo del código de autorización de OAuth 2 entre una aplicación de una página y el punto de conexión del servicio de token de seguridad.

Para ver este escenario en acción, consulte nuestro Tutorial: Inicio de sesión de usuarios y llamada a Microsoft Graph API desde una aplicación de página única (SPA) de JavaScript mediante un flujo de código de autorización.

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

Durante la mayor parte de la historia de OAuth 2.0, el flujo implícito ha sido la manera recomendada de compilar aplicaciones de página única. Con la eliminación de las cookies de terceros y la mayor atención a los problemas de seguridad relacionados con el flujo implícito, hemos pasado al flujo de código de autorización para aplicaciones de página única.

Para garantizar la compatibilidad de la aplicación en Safari y otros exploradores que tienen en cuenta la privacidad, ya no se recomienda utilizar el flujo implícito y, en su lugar, se recomienda el flujo de código de autorización.

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

// Partial content of a decoded ID token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

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:

Muestra el flujo de autenticación de aplicaciones web

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 ver este escenario en acción, pruebe los ejemplos de código del escenario de la aplicación web que inicia la sesión de los usuarios.

Además del inicio de sesión sencillo, una aplicación web de servidor podría tener la necesidad de acceder a otros servivio web, como una API de 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 más información sobre este escenario, lea acerca de cómo comenzar con aplicaciones web y API web.

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 eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
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:

Muestra el flujo de autenticación de API web

Para aprender a proteger una API web con tokens de acceso de OAuth2, consulte los ejemplos de código de API web del escenario 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, 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.

Muestra el flujo de autenticación de la aplicación nativa

Nota

Si la aplicación usa la vista previa 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 Azure AD.

Demonios y aplicaciones de servidor

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 más información, consulte este artículo sobre la aplicación de consola de demonio de .NET Core con 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:

Muestra el flujo de autenticación de la aplicación de demonio

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.

Pasos siguientes

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.