Share via

Flujos de autenticación admitidos en MSAL

  • Artículo

La Biblioteca de autenticación de Microsoft (MSAL) admite varias concesiones de autorización y flujos de token asociados para su uso por diferentes tipos de aplicaciones y escenarios.

Flujo de autenticación Habilita Tipos de aplicación admitidos
Código de autorización Inicio de sesión de usuario y acceso a las API web en nombre del usuario. * Escritorio
* Móvil
* Aplicación de página única (SPA) (requiere PKCE)
* Web
Credenciales de cliente Acceso a las API web mediante la identidad de la propia aplicación. Normalmente se usa para la comunicación de servidor a servidor y scripts automatizados que no requieren interacción del usuario. Demonio
Código del dispositivo Inicio de sesión de usuario y acceso a las API web en nombre del usuario en dispositivos con restricciones de entrada, como televisores inteligentes e Internet de las cosas (IoT). También lo usan las aplicaciones de la interfaz de línea de comandos (CLI). Móvil y escritorio
Concesión implícita Inicio de sesión de usuario y acceso a las API web en nombre del usuario. Ya no se recomienda el flujo de concesión implícita: use el código de autorización con la clave de prueba para El intercambio de código (PKCE) en su lugar. * Aplicación de página única (SPA)
* Web
Derechos delegados (OBO) Acceso desde una API web "ascendente" a una API web "descendente" en nombre del usuario. La identidad del usuario y los permisos delegados se pasan a la API descendente desde la API ascendente. API web
Nombre de usuario o contraseña (ROPC) Permite a una aplicación iniciar la sesión del usuario al controlar directamente la contraseña. No se recomienda el flujo de ROPC. Móvil y escritorio
Autenticación integrada de Windows (IWA) Permite que las aplicaciones de dominio o Microsoft Entra ID equipos unidos adquieran un token de forma silenciosa (sin ninguna interacción de la interfaz de usuario del usuario). Móvil y escritorio

Tokens

La aplicación puede usar uno o varios flujos de autenticación. Cada flujo usa determinados tipos de token para la autenticación, autorización y actualización de los tokens, y algunos también usan un código de autorización.

Flujo o acción de autenticación Requiere token de identificador Access token Token de actualización Código de autorización
Flujo de código de autorización ✅ ✅ ✅ ✅
Credenciales de cliente ✅ (solo aplicación)
Flujo de código de dispositivo ✅ ✅ ✅
Flujo implícito ✅ ✅
Flujo en nombre de Access token ✅ ✅ ✅
Nombre de usuario/contraseña (ROPC) Nombre de usuario, contraseña ✅ ✅ ✅
Flujo de OIDC híbrido ✅ ✅
Redención de token de actualización Token de actualización ✅ ✅ ✅

Autenticación interactiva y no interactiva

Varios de estos flujos admiten la adquisición interactiva y no interactiva de tokens.

  • Interactiva: es posible que el servidor de autorización solicite entrada por parte del usuario. Por ejemplo, para iniciar sesión, hacer la autenticación multifactor (MFA) o conceder consentimiento a más permisos de acceso a los recursos.
  • No interactiva: es posible que no se solicite entrada por parte del usuario. También se denomina adquisición silenciosa de tokens, la aplicación intenta obtener un token mediante un método en el que es posible que el servidor de autorización no solicite al usuario la entrada.

La aplicación basada en MSAL primero debe intentar adquirir un token de manera silenciosa y utilizar el método interactivo solo si se produce un error en el intento no interactivo. Para más información sobre este patrón, consulte Adquisición y almacenamiento en caché de tokens con la biblioteca de autenticación de Microsoft (MSAL).

Código de autorización

Las aplicaciones web, las aplicaciones de página única (SPA) y las aplicaciones nativas (móviles y de escritorio) pueden usar la concesión de código de autorización de OAuth 2.0 para obtener acceso a recursos protegidos, como las API web.

Cuando los usuarios inician sesión en aplicaciones web, la aplicación recibe un código de autorización que puede canjear por un token de acceso para llamar a las API web.

Diagrama del flujo de código de autorización

En el diagrama anterior, la aplicación hace lo siguiente:

  1. Solicita un código de autorización, que se canjea por un token de acceso.
  2. Usa el token de acceso para llamar a una API web, como Microsoft Graph.

Restricciones del código de autorización

  • Las aplicaciones de página única requieren una clave de prueba para Code Exchange (PKCE) al usar el flujo de concesión de código de autorización. MSAL admite PKCE.

  • La especificación de OAuth 2.0 requiere el uso de un código de autorización para canjear un token de acceso solo una vez.

    Si intenta adquirir un token de acceso varias veces con el mismo código de autorización, el Plataforma de identidad de Microsoft devuelve un error similar al siguiente. Tenga en cuenta que algunas bibliotecas y marcos de trabajo solicitan automáticamente el código de autorización y, si solicita un código manualmente en estos casos, también se producirá este error.

    AADSTS70002: Error validating credentials. AADSTS54005: OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token.

Credenciales de cliente

Es flujo de credenciales de cliente de OAuth 2 permite acceder a los recursos hospedados en la Web mediante la identidad de una aplicación. Este tipo de concesión se usa normalmente para las interacciones de servidor a servidor (S2S) que se deben ejecutar en segundo plano, sin interacción inmediata de un usuario. A menudo, estos tipos de aplicaciones se conocen como demonios o servicios.

El flujo de concesión de credenciales de cliente permite que un servicio web (cliente confidencial) use sus propias credenciales para autenticarse al llamar a otro servicio web, en lugar de suplantar a un usuario. En este escenario, el cliente suele ser un servicio web de nivel intermedio, un servicio demonio o un sitio web. Para conseguir un mayor nivel de control, la plataforma de identidad de Microsoft también permite que el servicio que realiza la llamada use un certificado (en lugar de un secreto compartido) como credencial.

Secretos de aplicación

Diagrama de cliente confidencial con contraseña

En el diagrama anterior, la aplicación hace lo siguiente:

  1. Adquiere un token mediante un secreto de aplicación o credenciales de contraseña.
  2. Usa el token para realizar solicitudes de recursos.

Certificados

Diagrama de cliente confidencial con certificado

En el diagrama anterior, la aplicación hace lo siguiente:

  1. Adquiere un token mediante el uso de credenciales de certificado.
  2. Usa el token para realizar solicitudes de recursos.

Este tipo de credenciales de cliente debe ser:

  • Registrarse en Azure AD.
  • Se pasa al construir el objeto de aplicación cliente confidencial en el código.

Restricciones de las credenciales de cliente

El flujo de cliente confidencial no se admite en plataformas móviles como Android, iOS o Plataforma universal de Windows (UWP). Las aplicaciones móviles se consideran aplicaciones cliente públicas que no pueden garantizar la confidencialidad de los secretos de autenticación.

Código del dispositivo

El flujo de código del dispositivo OAuth 2 permite a los usuarios iniciar sesión en dispositivos con restricciones de entrada, como televisores inteligentes, dispositivos de Internet de las cosas (IoT) e impresoras. La autenticación interactiva con Microsoft Entra ID requiere un explorador web. Cuando el dispositivo o el sistema operativo no proporcionan un explorador web, el flujo de código del dispositivo permite usar otro dispositivo, como un equipo o un teléfono móvil, para iniciar sesión de forma interactiva.

Al usar el flujo de código del dispositivo, la aplicación obtiene los tokens a través de un proceso de dos pasos diseñado para estos dispositivos y sistemas operativos.

Diagrama del flujo de código de dispositivo

En el diagrama anterior:

  1. Cada vez que se requiera autenticación del usuario, la aplicación proporciona un código y pide al usuario que use otro dispositivo, como un smartphone conectado a Internet, para ir a una dirección URL (por ejemplo, https://microsoft.com/devicelogin). A continuación, se le pide al usuario que escriba el código y continúe a través de una experiencia de autenticación normal, incluidas las solicitudes de consentimiento y la autenticación multifactor, si es necesario.
  2. Tras la autenticación correcta, la aplicación solicitante recibe los tokens necesarios de la Plataforma de identidad de Microsoft y los usa para realizar las llamadas a la API web que necesita.

Restricciones del código del dispositivo

  • El flujo de código de dispositivo solo está disponible en las aplicaciones cliente públicas.
  • Al inicializar una aplicación cliente pública en MSAL, use uno de estos formatos de autoridad:
    • Basado en inquilinos: https://login.microsoftonline.com/{tenant}/, donde {tenant} es el GUID que representa el identificador de inquilino o un nombre de dominio asociado al inquilino.
    • Cuentas profesionales y educativas: https://login.microsoftonline.com/organizations/.

Concesión implícita

La concesión implícita se ha reemplazado mediante el flujo del código de autorización con PKCE como el flujo de concesión de tokens preferido y más seguro para las aplicaciones de página única (SPA) del lado del cliente. Si va a crear una SPA, use el flujo del código de autorización con PKCE en su lugar.

Las aplicaciones web de página única escritas en JavaScript (incluidos los marcos como Angular, Vue.js o React.js) se descargan desde el servidor y su código se ejecuta directamente en el explorador. Dado que su código del lado cliente se ejecuta en el explorador y no en un servidor web, tienen características de seguridad diferentes de las aplicaciones web tradicionales del lado servidor. Antes de la disponibilidad de la clave de prueba para el intercambio de código (PKCE) para el flujo de código de autorización, las SPA usaban el flujo de concesión implícita para mejorar la capacidad de respuesta y la eficacia en la obtención de tokens de acceso.

El flujo de concesión implícita de OAuth 2 permite a la aplicación obtener tokens de acceso desde la plataforma de identidad de Microsoft sin tener que hacer un intercambio de credenciales del servidor back-end. El flujo de concesión implícita permite a una aplicación iniciar la sesión del usuario, mantener una sesión y obtener tokens para otras API web desde el código JavaScript que descarga y ejecuta el agente de usuario (normalmente un explorador web).

Diagrama del flujo de concesión implícito

Restricciones de la concesión implícita

El flujo de concesión implícita no incluye escenarios de aplicación que usan marcos de JavaScript multiplataforma como Electron o React Native. Los marcos multiplataforma, como estos, requieren funcionalidades adicionales para la interacción con las plataformas móviles y de escritorio nativas en las que se ejecutan.

Los tokens emitidos a través del modo de flujo implícito tienen una limitación de longitud porque se devuelven al explorador en la dirección URL (donde response_mode es query o fragment). Algunos exploradores limitan la longitud de la dirección URL en la barra del explorador y generan un error cuando es demasiado larga. Por lo tanto, estos tokens de flujo implícitos no contienen notificaciones groups o wids.

Derechos delegados (OBO)

El flujo de flujo de autenticación en nombre de OAuth 2 se usa cuando una aplicación invoca un servicio o UNA API web que, a su vez, necesita llamar a otro servicio o API web mediante una identidad de usuario delegada y permisos que necesitan propagarse a través de la cadena de solicitudes. Para que el servicio de nivel intermedio realice solicitudes autenticadas en el servicio de bajada, debe proteger un token de acceso del Plataforma de identidad de Microsoft en nombre del usuario solicitante.

Diagrama del flujo

En el diagrama anterior:

  1. La aplicación adquiere un token de acceso para la API web.
  2. Un cliente (web, aplicación de escritorio, aplicación móvil o una página) llama a una API web protegida, agregando el token de acceso como token de portador en el encabezado de autenticación de la solicitud HTTP. La API web autentica al usuario.
  3. Cuando el cliente llama a la API web, la API web solicita otro token en nombre del usuario.
  4. La API web protegida usa este token para llamar a una API web de bajada en nombre del usuario. La API web también puede solicitar tokens más tarde para otras API descendentes (pero todavía en nombre del mismo usuario).

Nombre de usuario/contraseña (ROPC)

Advertencia

Ya no se recomienda el flujo de credenciales de contraseña del propietario del recurso (ROPC). ROPC requiere un alto grado de confianza y exposición de credencial. Use solo ROPC si no se puede usar un flujo más seguro. Para más información, consulte What's the solution to the growing problem of passwords? (¿Cuál es la solución al creciente problema de las contraseñas?).

La concesión de credenciales de contraseña de propietario de recurso de OAuth 2 (ROPC) permite que una aplicación inicie la sesión del usuario al controlar directamente la contraseña. En la aplicación de escritorio, puede usar el flujo de usuario y contraseña para adquirir un token de forma silenciosa. No se requiere ninguna interfaz de usuario cuando se usa la aplicación.

Algunos escenarios de aplicación, como DevOps, pueden resultar útiles roPC, pero debe evitarlo en cualquier aplicación en la que proporcione una interfaz de usuario interactiva para el inicio de sesión del usuario.

Diagrama del flujo de usuario y contraseña

En el diagrama anterior, la aplicación hace lo siguiente:

  1. Adquiere un token al enviar el nombre de usuario y contraseña al proveedor de identidades.
  2. Llama a una API web mediante el token.

Para adquirir un token de forma silenciosa en máquinas unidas a un dominio de Windows, se recomienda usar el Administrador de cuentas web (WAM) en lugar de ROPC. Para otros escenarios, use el flujo de código de dispositivo.

Restricciones de ROPC

Las restricciones siguientes se aplican a las aplicaciones que usan el flujo de ROPC:

  • No se admite el inicio de sesión único.
  • No se admite la autenticación multifactor (MFA).
    • Consulte con el administrador de inquilinos antes de usar este flujo: MFA es una característica de uso frecuente.
  • No se admite el acceso condicional.
  • ROPC solo funciona para las cuentas profesionales y educativas.
  • ROPC no admite las cuentas de Microsoft (MSA) personales.
  • ROPC se admite en aplicaciones de escritorio y .NET de .NET.
  • ROPC no se admite en aplicaciones de la Plataforma universal de Windows (UWP).
  • ROPC en Id. externa de Microsoft Entra solo se admite para las cuentas locales.

Autenticación integrada de Windows (IWA)

Nota

La autenticación integrada de Windows se ha reemplazado por una forma más confiable de obtener tokens de forma silenciosa: WAM. WAM puede iniciar sesión el usuario actual de Windows de forma silenciosa. Este flujo de trabajo no requiere una configuración compleja e incluso funciona para cuentas personales (Microsoft). Internamente, Windows Broker (WAM) probará varias estrategias para obtener un token para el usuario actual de Windows, incluido IWA y canjear el PRT. Esto elimina la mayoría de las limitaciones de IWA.

MSAL admite autenticación de Windows integrados (IWA) para aplicaciones móviles y de escritorio que se ejecutan en equipos Windows unidos a un dominio o Microsoft Entra ID unidos. Mediante IWA, estas aplicaciones adquieren un token de forma silenciosa, sin que el usuario interactúe con la UI.

Diagrama de la autenticación integrada de Windows

En el diagrama anterior, la aplicación hace lo siguiente:

  1. Adquiere un token mediante el uso de la autenticación integrada de Windows.
  2. Usa el token para realizar solicitudes de recursos.

Restricciones de IWA

  • Compatibilidad. La autenticación de Windows integrada (IWA) está habilitada para aplicaciones de escritorio, .NET y Plataforma universal de Windows (UWP). IWA solo admite usuarios federados de ADFS: usuarios creados en Active Directory y respaldados por Microsoft Entra ID. Los usuarios creados directamente en Microsoft Entra ID sin respaldo de Active Directory (usuarios administrados) no pueden usar este flujo de autenticación.
  • Autenticación multifactor (MFA). La autenticación IWA no interactiva (silenciosa) puede producir un error si MFA está habilitado en el inquilino de Microsoft Entra ID y Microsoft Entra ID emite un desafío de MFA. Si se produce un error en IWA, debe volver a un método interactivo de autenticación como se describió anteriormente. Microsoft Entra ID usa ia para determinar cuándo se requiere la autenticación en dos fases. La autenticación en dos fases suele ser necesaria cuando un usuario inicia sesión desde otro país o región, cuando se conecta a una red corporativa sin usar una VPN y, a veces, cuando se conecta mediante una VPN. Dado que la configuración y la frecuencia de desafío de MFA pueden estar fuera del control como desarrollador, la aplicación debe controlar correctamente un error en la adquisición silenciosa de tokens IWA.
  • Restricciones de URI de autoridad. La autoridad que se pasa al construir la aplicación cliente pública debe ser una de las siguientes:
    • https://login.microsoftonline.com/{tenant}/: esta autoridad indica una aplicación de un solo inquilino cuya audiencia de inicio de sesión está restringida a los usuarios del inquilino de Microsoft Entra ID especificado. El valor {tenant} puede ser el identificador de inquilino en formato GUID o el nombre de dominio asociado al inquilino.
    • https://login.microsoftonline.com/organizations/: esta autoridad indica una aplicación multiinquilino cuya audiencia de inicio de sesión es usuarios en cualquier inquilino de Microsoft Entra ID.
  • Cuentas personales. Los valores de autoridad no deben contener /common ni /consumers porque IWA no admite cuentas personales de Microsoft (MSA).
  • Requisitos de consentimiento. Dado que IWA es un flujo silencioso, el usuario de la aplicación debe haber dado su consentimiento previamente para usar la aplicación o el administrador de inquilinos debe haber dado su consentimiento previamente a todos los usuarios del inquilino para usar la aplicación. Para satisfacer cualquiera de los requisitos, se debe haber completado una de estas operaciones:

Pasos siguientes

Ahora que ha revisado los flujos de autenticación admitidos por MSAL, obtenga información sobre cómo adquirir y almacenar en caché los tokens usados en estos flujos.