Compatibilidad con el flujo de autenticación de MSAL

  • Artículo

La biblioteca de autenticación de Microsoft (MSAL) admite varias concesiones de autorización y flujos de tokens asociados para utilizarlos en diferentes tipos y escenarios de aplicación.

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. Dispositivo de escritorio
Mobile
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 y dispositivos de 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 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 a los equipos de aplicaciones en equipos unidos a un dominio o a Microsoft Entra adquirir un token de manera 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 El flujo de autenticación funciona para el token de identificador El flujo de autenticación funciona para el token de acceso El flujo de autenticación funciona para el token de actualización El código de autorización funciona
Credenciales de cliente El flujo de autenticación funciona para el token de acceso (solo aplicación)
Flujo de código de dispositivo El flujo de autenticación funciona para el token de identificador El flujo de autenticación funciona para el token de acceso El flujo de autenticación funciona para el token de actualización
Flujo implícito El flujo de autenticación funciona para el token de identificador El flujo de autenticación funciona para el token de acceso
Flujo en nombre de de la aplicación Twitter El flujo de autenticación funciona para el token de identificador El flujo de autenticación funciona para el token de acceso El flujo de autenticación funciona para el token de actualización
Nombre de usuario/contraseña (ROPC) nombre de usuario, contraseña El flujo de autenticación funciona para el token de identificador El flujo de autenticación funciona para el token de acceso El flujo de autenticación funciona para el token de actualización
Flujo de OIDC híbrido El flujo de autenticación funciona para el token de identificador El código de autorización funciona
Redención de token de actualización Token de actualización El flujo de autenticación funciona para el token de identificador El flujo de autenticación funciona para el token de acceso El flujo de autenticación funciona para el 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 (silenciosa): es posible que no se solicite entrada por parte del usuario. También denominada adquisición de tokens "silenciosa", la aplicación intenta obtener un token mediante un método en el que el servidor de autorización quizás 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 (para móviles y de escritorio) pueden usar la concesión de código de autorización de OAuth 2.0 para obtener acceso a los 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.

En el diagrama siguiente, la aplicación:

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

Diagrama del flujo de código de autorización.

Restricciones del código de autorización

  • Las aplicaciones de página única requieren la clave de prueba para el intercambio de código (PKCE) al usar el flujo de concesión del 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 el token de acceso varias veces con el mismo código de autorización, la plataforma de identidad de Microsoft devuelve un error similar al siguiente. 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

El flujo de credenciales de cliente de OAuth 2.0 permite acceder a los recursos hospedados en la Web mediante la identidad de una aplicación. Este tipo de concesión se usa principalmente para las interacciones entre servidores que se deben ejecutar en segundo plano, sin la interacción inmediata con un usuario. Estos tipos de aplicaciones suelen denominarse demonios o cuentas de servicio.

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

En el diagrama siguiente, la aplicación:

  1. Adquiere un token al usar un secreto de aplicación o credenciales de contraseña
  2. Usa el token para hacer solicitudes al recurso

Diagrama de cliente confidencial con contraseña.

Certificados

En el diagrama siguiente, la aplicación:

  1. Adquiere un token mediante el uso de credenciales de certificado
  2. Usa el token para hacer solicitudes al recurso

Diagrama de cliente confidencial con certificado.

Estas credenciales de cliente deben:

  • Registrado con Microsoft Entra ID
  • 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 UWP. Las aplicaciones móviles se consideran aplicaciones cliente públicas que no pueden garantizar la confidencialidad de sus credenciales.

Código del dispositivo

El flujo de código del dispositivo de OAuth 2.0 permite que los usuarios inicien sesión en dispositivos con restricción de entrada como televisores inteligentes, dispositivos IoT e impresoras. La autenticación interactiva con Microsoft Entra ID requiere un explorador web. Cuando el dispositivo o el sistema operativo no proporciona un explorador web, el flujo de código de dispositivo permite que el usuario utilice otro dispositivo, como un equipo o un teléfono móvil para iniciar sesión de manera 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. Entre algunos ejemplos de estas aplicaciones se incluye aquellas que se ejecutan en dispositivos IoT o herramientas de interfaz de la línea de comandos (CLI).

En el diagrama siguiente:

  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). Luego, se le pide al usuario que especifique el código y el usuario pasa por una experiencia de autenticación normal, como peticiones de consentimiento y autenticación multifactor, si es necesario.
  2. Tras una autenticación correcta, la aplicación de línea de comandos recibe los tokens necesarios a través de un canal posterior y los usa para realizar las llamadas a la API web que necesita.

Diagrama de flujo de código del dispositivo.

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:
    • Inquilino: https://login.microsoftonline.com/{tenant}/, donde {tenant} es el identificador del inquilino o un dominio asociado con el inquilino.
    • Cuentas profesionales y educativas: https://login.microsoftonline.com/organizations/.

Concesión implícita

El flujo de 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. Ya no se recomienda usar el flujo de concesión implícita. 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.0 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 más funcionalidades para la interacción con las plataformas nativas de escritorio y móviles en las que se ejecutan.

Los tokens emitidos a través del modo de flujo implícito tienen una limitación de longitud, porque son devueltos al explorador por 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 autenticación delegada de OAuth 2.0 se usa cuando una aplicación invoca un servicio o una API web que, a su vez, necesita llamar a otro servicio o a otra API web. La idea es propagar la identidad y los permisos del usuario delegado a través de la cadena de solicitud. Para que el servicio de nivel intermedio realice solicitudes autenticadas al servicio de bajada, debe proteger un token de acceso de la plataforma de identidad de Microsoft en nombre del usuario.

En el diagrama siguiente:

  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, esta solicita otro token en nombre del usuario.
  4. La API web protegida usa este token para llamar a una API web descendente 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).

Diagrama de flujo

Nombre de usuario/contraseña (ROPC)

Advertencia

No se recomienda el flujo de credenciales de contraseña del propietario de recursos (ROPC). ROPC requiere un alto grado de confianza y exposición de credencial. Recurra al uso de ROPC solo 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.0 (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 podrían resultar útiles para ROPC, pero debe evitarlo en cualquier aplicación en la que proporcione una UI interactiva para el inicio de sesión del usuario.

En el diagrama siguiente, la aplicación:

  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.

Diagrama de flujo de usuario y contraseña.

Para adquirir un token de forma silenciosa en las máquinas Windows unidas a un dominio, se recomienda la autenticación integrada de Windows (IWA) 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 de .NET y ASP.NET Core.
  • ROPC no se admite en aplicaciones de la Plataforma universal de Windows (UWP).
  • ROPC en Azure AD B2C solo se admite para cuentas locales.

Autenticación integrada de Windows (IWA)

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

En el diagrama siguiente, la aplicación:

  1. Adquiere un token mediante la autenticación integrada de Windows
  2. Usa el token para hacer solicitudes al recurso

Diagrama de la autenticación integrada de Windows.

Restricciones de IWA

Compatibilidad

La Autenticación integrada de Windows (IWA) está habilitada para escritorio de .NET, .NET y aplicaciones de la plataforma universal de Windows.

IWA admite solo usuarios federados de AD FS, es decir, 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 utilizar este flujo de autenticación.

Autenticación multifactor (MFA)

La autenticación no interactiva (silenciosa) de IWA puede producir un error si MFA está habilitada en el inquilino de Microsoft Entra y Microsoft Entra 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 la IA para determinar cuando 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 de su control como desarrollador, la aplicación debe controlar correctamente un error de adquisición silenciosa de tokens de 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 entidad 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 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 entidad indica una aplicación multiinquilino cuya audiencia de inicio de sesión son usuarios de cualquier inquilino de Microsoft Entra.

Los valores de autoridad NO deben contener /common o /consumers porque IWA no admite cuentas de Microsoft (MSA) personales.

Requisitos del consentimiento

Dado que IWA es un flujo silencioso:

  • El usuario de la aplicación debe haber consentido anteriormente para usar la aplicación.

    OR

  • El administrador de inquilinos debe haber consentido anteriormente a todos los usuarios en el inquilino para que usen la aplicación.

Para satisfacer cualquiera de los requisitos, se debe haber completado una de estas operaciones:

  • Usted, como desarrollador de la aplicación, seleccionó Conceder en Azure Portal para sí mismo.
  • Un administrador de inquilinos ha seleccionado Conceder o revocar consentimiento del administrador para {dominio del inquilino} en la pestaña Permisos de API del registro de la aplicación en Azure Portal. Consulte Incorporación de permisos para acceder a la API web.
  • Ha proporcionado una manera para que los usuarios den su consentimiento a la aplicación. Consulte Consentimiento del usuario.
  • Ha proporcionado una manera para que el administrador de inquilinos dé su consentimiento para la aplicación. Consulte Consentimiento de administrador.

Para más información sobre el consentimiento, consulte Permisos y consentimiento.

Paso siguiente

Obtenga información sobre cómo adquirir y almacenar en caché los tokens usados en estos flujos:

Adquisición y almacenamiento en caché de tokens con la biblioteca de autenticación de Microsoft (MSAL)