Consideraciones de alta disponibilidad en MSAL.NET

Para ver el flujo de credenciales de cliente, consulte primero la documentación de flujos de credenciales de cliente .

Uso de una API de nivel superior

MSAL es una API de nivel inferior. Si va a escribir una nueva aplicación, considere la posibilidad de usar el nivel Microsoft.Identitity.Web superior que proporciona integración integrada con ASP.NET Core y ASP.NET clásico.

Uso de la versión más reciente de MSAL

Use la versión más reciente de MSAL para obtener las correcciones de errores y las mejoras de rendimiento. Se siguen las reglas de control de versiones semánticas.

También conviene comprobar si debe usar Microsoft Identity Web, una biblioteca de nivel superior para aplicaciones web y API web, que realiza gran parte de lo que se describe a continuación por usted. Consulte Elección de una versión de MSAL.NET, que propone un árbol de decisión para elegir la mejor solución en función de la plataforma y las restricciones.

Utilice la caché de tokens

Comportamiento predeterminado: MSAL almacena en caché los tokens en memoria. Cada ConfidentialClientApplication instancia tiene su propia caché de tokens interna. La memoria caché en memoria se puede perder, por ejemplo, si se elimina la instancia del objeto o se detiene toda la aplicación.

Recomendación: Todas las aplicaciones deben conservar sus cachés de tokens. Las aplicaciones web y las API web deben usar una caché de tokens L1/L2 donde L2 es un almacén distribuido como Redis para controlar la escala. Las aplicaciones de escritorio deben usar una estrategia de serialización de caché de tokens adecuada.

Comportamiento predeterminado: MSAL mantiene una caché de tokens de ADAL secundaria para escenarios de migración entre ADAL y MSAL. Las operaciones de caché de ADAL son muy lentas. Recomendación: Deshabilite la caché de ADAL si no está interesado en migrar desde ADAL. Esto supondrá una GRAN mejora en el rendimiento; consulte las mediciones de rendimiento aquí.

Agregue WithLegacyCacheCompatibility(false) al construir la aplicación para deshabilitar el almacenamiento en caché de ADAL.

Adición de supervisión en torno a las operaciones de MSAL

MSAL expone métricas importantes como parte del objeto AuthenticationResult.AuthenticationResultMetadata :

Logging

Presta atención a los mensajes de nivel Warning y Error procedentes de los registros de MSAL. Estos pueden ser errores silenciosos o recomendaciones firmes para usar una configuración diferente. No se recomienda activar el registro Verbose en producción, ya que genera muchos mensajes y afecta al rendimiento.

Puede encontrar detalles sobre el registro en la guía registro en MSAL.NET.

Directiva de reintentos

Comportamiento predeterminado: MSAL reintentará las solicitudes 5xx con error una vez.

Recomendación:

• Consulte nuestra documentación sobre la política de reintentos para escribir una política de reintentos con Polly.

Un cliente confidencial por sesión

Se recomienda usar un nuevo ConfidentialClientApplication en cada sesión y serializar de la misma manera: una caché de tokens por sesión. Esto es escalable y además aumenta la seguridad. Los ejemplos oficiales muestran cómo hacerlo. Debe configurar el almacenamiento en caché de tokens para que funcione correctamente.

Cliente HTTP

Comportamiento predeterminado: el HttpClient creado por MSAL no escala bien para sitios web o API web donde se recomienda tener un objeto ClientApplication para cada sesión de usuario.

Recomendación: Proporcione su propia HttpClientFactory escalable. En .NET Core, recomendamos que inyecte el System.Net.Http.IHttpClientFactory. Esto se describe con más detalle en la guía Cómo proporcionar su propio HttpClient, compatibilidad con proxies HTTP y personalización de las cabeceras User-Agent y en la documentación de .NET

Renovación proactiva de tokens

Objetivo

Aumente la disponibilidad de las aplicaciones mediante la emisión de tokens de acceso de larga duración y asegúrese de que se actualizan antes de su fecha de expiración.

Status quo

De forma predeterminada, Microsoft Entra ID emite tokens de acceso con una expiración de 1 hora. Si se produce una caída de Microsoft Entra cuando es necesario actualizar un token, MSAL fallará. El error se propaga a la aplicación que llama y afecta a la disponibilidad.

Proceso

Para mejorar la disponibilidad MSAL intenta asegurarse de que una aplicación siempre tiene tokens no expirados nuevos. Las interrupciones de Microsoft Entra rara vez duran más de unas pocas horas, por lo que, si MSAL puede garantizar que un token siempre tenga al menos unas pocas horas de validez restante, la aplicación no se verá afectada por una interrupción de Microsoft Entra.

Para obtener tokens de larga duración, debes configurar tu tenant (nota: los tenants internos de Microsoft ya están configurados). Para client_credentials (servicio 2), esto es suficiente. Para las credenciales de usuario, también debes configurar CAE: /azure/active-directory/conditional-access/concept-continuous-access-evaluation.

Cuando Microsoft Entra ID devuelve un token de larga duración, incluye un campo refresh_in. Por lo general, se establece en la mitad del tiempo de validez del token de acceso.

Nota: A partir de MSAL 4.37.0, puede observar este valor inspeccionando el AuthenticationResult.AuthenticationResultMetadata.RefreshOn.

Además, puede configurar un período de validez de un token superior al valor predeterminado de 1 hora, como se describe en Períodos de validez de tokens configurables en la plataforma de identidad de Microsoft (versión preliminar).

Siempre que realice solicitudes para el mismo token, es decir, siempre que MSAL pueda servir un token desde su caché, MSAL comprobará automáticamente el refresh_in valor. Si ha transcurrido, MSAL emitirá una solicitud de token para Microsoft Entra ID en segundo plano, pero devolverá el token válido existente a la aplicación. En el improbable caso de que falle la actualización en segundo plano (por ejemplo, debido a una interrupción de Microsoft Entra), la aplicación no se ve afectada.

Rotación de certificados

Los certificados de la aplicación cliente confidencial deben renovarse por motivos de seguridad (¡no utilices secretos en producción!). Hay varias maneras de controlar la rotación de certificados, en orden del más preferido al menos:

1. Uso de identidad administrada

Con la identidad administrada, la confianza se establece mediante el hospedaje de la aplicación en Azure. No hay secretos que gestionar ni certificados que rotar.

2. Use la lógica de gestión de Microsoft.Identity.Web certificados

En las aplicaciones web y las API web, use Microsoft.Identity.Web, una API de nivel superior a través de MSAL. Controla la rotación de certificados cuando el certificado se almacena en Azure Key Vault y también controla el caso de identidad administrada.

Obtenga más información en Certificados en Microsoft. Guía de Identity.Web.

Esta es la solución preferida para los servicios internos que no son Microsoft mediante ASP.NET Core.

3. (Solo para uso interno de Microsoft) Confíe en los certificados de nombre del sujeto/emisor.

Este mecanismo permite Microsoft Entra ID identificar un certificado basado en SN/I en lugar de una huella digital (x5t). Es una solución provisional; no hay planes de ponerla a disposición de aplicaciones ajenas a Microsoft.

Esta es la solución preferida para Microsoft servicios internos que no pueden usar la identidad administrada.