Aumento de la resistencia de la autenticación y la autorización en las aplicaciones cliente que se desarrollan

Artículo
10/25/2023

Aprenda a aumentar la resistencia en aplicaciones cliente que usen la Plataforma de identidad de Microsoft y Microsoft Entra ID para el inicio de sesión de los usuarios y la ejecución de acciones en nombre de estos.

Uso de la Biblioteca de autenticación de Microsoft (MSAL)

La Biblioteca de autenticación de Microsoft (MSAL) es parte de la Plataforma de identidad de Microsoft. MSAL adquiere, administra, almacena en caché y actualiza tokens; usa procedimientos recomendados para la resistencia. MSAL ayuda a los desarrolladores a crear soluciones seguras.

Más información:

MSAL almacena en caché los tokens y usa un patrón de adquisición de tokens silencioso. MSAL serializa la caché de tokens en sistemas operativos que proporcionan almacenamiento seguro de forma nativa, como Plataforma universal de Windows (UWP), iOS y Android. Personalice el comportamiento de serialización cuando use:

Microsoft.Identity.Web
MSAL.NET
MSAL para Java
MSAL para Python

Más información:

Al usar MSAL, se admite el almacenamiento en caché de tokens, la actualización y la adquisición silenciosa. Use patrones sencillos para adquirir los tokens para la autenticación. Hay compatibilidad con muchos idiomas. Encuentre muestras de código en Muestras de código de la plataforma de identidad de Microsoft.

C#
JavaScript

try
{
    result = await app.AcquireTokenSilent(scopes, account).ExecuteAsync();
}
catch(MsalUiRequiredException ex)
{
    result = await app.AcquireToken(scopes).WithClaims(ex.Claims).ExecuteAsync()
}

return myMSALObj.acquireTokenSilent(request).catch(error => {
    console.warn("silent token acquisition fails. acquiring token using redirect");
    if (error instanceof msal.InteractionRequiredAuthError) {
        // fallback to interaction when silent call fails
        return myMSALObj.acquireTokenPopup(request).then(tokenResponse => {
            console.log(tokenResponse);

            return tokenResponse;
        }).catch(error => {
            console.error(error);
        });
    } else {
        console.warn(error);
    }
});

MSAL puede actualizar tokens. Cuando la plataforma de identidad de Microsoft emite los tokens de larga duración, puede enviar información al cliente para refrescar el token (refresh_in). La aplicación se ejecuta mientras el token anterior es válido, pero tarda más tiempo en adquirir otro token.

Versiones de MSAL

Recomendamos a los desarrolladores que creen un proceso para usar la última versión de MSAL porque la autenticación forma parte de la seguridad de las aplicaciones. Use esta práctica para las bibliotecas en desarrollo y mejore la resistencia de las aplicaciones.

Busque la versión más reciente y las notas de la versión:

Patrones resistentes para el control de tokens

Si no usa MSAL, use patrones resistentes para el control de tokens. La biblioteca MSAL implementa los procedimientos recomendados.

En general, las aplicaciones que usan autenticación moderna llaman a un punto de conexión para recuperar los tokens que autentican al usuario o autorizan a la aplicación a llamar a API protegidas. MSAL controla la autenticación e implementa patrones para mejorar la resistencia. Si no usa MSAL, use las instrucciones de esta sección para conocer los procedimientos recomendados. De lo contrario, MSAL implementa los procedimientos recomendados de manera automática.

Almacenamiento de tokens en caché

Asegúrese de que las aplicaciones almacenan en caché los tokens con precisión desde la Plataforma de identidad de Microsoft. Una vez que la aplicación recibe tokens, la respuesta HTTP con tokens tiene una propiedad expires_in que indica la duración de la memoria caché y cuándo reutilizarla. Confirme que la aplicación no intenta descodificar un token de acceso de API.

Diagrama de una aplicación que llama a la plataforma de identidad de Microsoft, a través de una caché de tokens en el dispositivo que ejecuta la aplicación.

Los tokens almacenados en caché evitan el tráfico innecesario entre una aplicación y la plataforma de identidad de Microsoft. Este escenario hace que la aplicación sea menos susceptible a los errores de adquisición de tokens al reducir las llamadas de adquisición de tokens. Los tokens almacenados en caché mejoran el rendimiento de la aplicación, ya que la aplicación bloquea la adquisición de tokens con menos frecuencia. Los usuarios permanecen conectados a su aplicación durante la vida útil de los tokens.

Serialización y conservación de tokens

Garantice que las aplicaciones serializan su caché de tokens de forma segura para persistir los tokens entre instancias de la aplicación. Reutilice los tokens durante su vigencia. Los tokens de actualización y los tokens de acceso se emiten durante muchas horas. Durante este tiempo, los usuarios pueden iniciar la aplicación varias veces. Cuando se inicia una aplicación, confirme que busca acceso válido o un token de actualización. Esto aumenta la resistencia y el rendimiento de la aplicación.

Más información:

Asegúrese de que el almacenamiento de tokens persistente tenga el control de acceso y el cifrado, en relación con el propietario del usuario o la identidad del proceso. En varios sistemas operativos, hay características de almacenamiento de credenciales.

Adquisición silenciosa de tokens

La autenticación de un usuario o la obtención de autorización para llamar a una API conlleva varios pasos en la plataforma de identidades de Microsoft. Por ejemplo, los usuarios que inician sesión por primera vez escriben credenciales y realizan una autenticación multifactor. Cada paso afecta al recurso que proporciona el servicio. La mejor experiencia para el usuario con la menor cantidad de dependencias es la adquisición silenciosa de los tokens.

Diagrama de los servicios de la plataforma de identidad de Microsoft que ayudan a completar la autenticación o autorización del usuario.

La adquisición silenciosa de tokens comienza con un token válido de la caché de tokens de la aplicación. Si no hay un token válido, la aplicación intenta adquirir un token usando un token de actualización disponible y el punto de conexión del token. Si ninguna de las dos opciones está disponible, la aplicación adquiere los tokens usando el parámetro prompt=none. Esta acción usa el punto de conexión de autorización, pero no aparece ninguna interfaz de usuario para el usuario. Si es posible, la plataforma de identidad de Microsoft proporciona los tokens a la aplicación sin interacción del usuario. Si ningún método da como resultado los tokens, después el usuario vuelve a autentificarse manualmente.

Nota:

En general, garantice que las aplicaciones no usen solicitudes como "inicio de sesión" y "consentimiento". Estas solicitudes fuerzan la interacción del usuario, cuando no se requiere ninguna interacción.

Control de código de respuesta

Use las siguientes secciones para obtener información sobre los códigos de respuesta.

Código de respuesta HTTP 429

Hay respuestas de error que afectan a la resistencia. Si su aplicación recibe un código de respuesta HTTP 429, Demasiadas solicitudes, la plataforma de identidad de Microsoft está limitando sus solicitudes. Si una aplicación realiza demasiadas solicitudes, se limita su velocidad para evitar que reciba tokens. No permita que una aplicación intente adquirir tokens antes de que se complete el tiempo del campo de respuesta Retry-After. A menudo, una respuesta 429 indica que la aplicación no está almacenando en caché y reutilizando los tokens correctamente. Confirme cómo se almacenan en caché los tokens y cómo se reutilizan en la aplicación.

Código de respuesta HTTP 5x

Si una aplicación recibe un código de respuesta HTTP 5x, la aplicación no debe entrar en un bucle de reintento rápido. Use el mismo control para una respuesta 429. Si no aparece ningún encabezado Retry-After, implemente un reintento de retroceso exponencial con el primer reintento, al menos 5 segundos después de la respuesta.

Cuando se agota el tiempo de espera de una solicitud, se desaconsejan los reintentos inmediatos. Implemente un reintento de retroceso exponencial con el primer reintento al menos 5 segundos después de la respuesta.

Muchas aplicaciones y API necesitan información de usuario para autorizar. Los métodos disponibles tienen ventajas y desventajas.

Tokens

Los tokens de identidad (Id.) y los tokens de acceso tienen notificaciones estándar que proporcionan información. Si la información necesaria está en el token, la técnica más eficaz es la reclamación de tokens, porque así se evita otra llamada a la red. Menos llamadas de red equivalen a una mejor resistencia.

Más información:

Nota

Algunas aplicaciones llaman al punto de conexión UserInfo para recuperar notificaciones sobre el usuario autenticado. La información del token de identidad es un superconjunto de la información del punto de conexión UserInfo. Permite a las aplicaciones usar los tokens de id. en lugar de llamar al punto de conexión UserInfo.

Aumente las reivindicaciones estándar de los tokens con reivindicaciones opcionales, como los grupos. La opción Grupo de aplicaciones incluye los grupos asignados a la aplicación. Las opciones Todos o Grupos de seguridad incluyen grupos de aplicaciones del mismo inquilino, que pueden agregar grupos a los tokens. Evalúe el efecto, ya que puede anular la eficacia de solicitar grupos en los tokens al provocar el sobredimensionamiento de los tokens y requerir más llamadas para obtener los grupos.

Más información:

Recomendamos usar e incluir roles de aplicación, que los clientes administran usando el portal o las API. Asigne roles a usuarios y grupos para controlar el acceso. Cuando se emite un token, los roles asignados se encuentran en la notificación de roles del token. La información derivada de un token impide más llamadas API.

Consulte, Incorporación de roles de aplicación a una aplicación y su recepción en el token

Agregue notificaciones basadas en la información del inquilino. Por ejemplo, una extensión tiene un identificador de usuario específico de la empresa.

Agregar información del directorio a un token es eficaz y aumenta la resistencia al reducir las dependencias. No aborda los problemas de resistencia debido a la incapacidad de adquirir un token. Agregue notificaciones opcionales para los escenarios principales de la aplicación. Si la aplicación requiere información para la funcionalidad administrativa, la aplicación puede obtener esa información, según sea necesario.

Microsoft Graph

Microsoft Graph tiene un punto de conexión de API unificado para acceder a los datos de Microsoft 365 sobre patrones de productividad, identidad y seguridad. Las aplicaciones que usan Microsoft Graph pueden usar la información de Microsoft 365 para la autorización.

Las aplicaciones requieren un token para acceder a Microsoft 365, que es más resistente que las API anteriores para componentes de Microsoft 365, como Microsoft Exchange o Microsoft SharePoint, que requieren varios tokens.

Al usar las API de Microsoft Graph, use un SDK de Microsoft Graph que simplifique la creación de aplicaciones resistentes que acceden a Microsoft Graph.

Consulte Introducción al SDK de Microsoft Graph.

Para la autorización, considere la posibilidad de usar notificaciones de token en lugar de algunas llamadas de Microsoft Graph. Solicite grupos, roles de aplicación y reclamaciones opcionales en los tokens. Microsoft Graph para la autorización requiere más llamadas de red que se basan en la plataforma de identidad de Microsoft y Microsoft Graph. Sin embargo, si la aplicación se basa en Microsoft Graph como capa de datos, Microsoft Graph para la autorización no es más arriesgado.

Uso de la autenticación de agente en dispositivos móviles

En los dispositivos móviles, un agente de autenticación como Microsoft Authenticator mejora la resistencia. El agente de autenticación usa un token de actualización principal (PRT) con notificaciones sobre el usuario y el dispositivo. Use PRT para los tokens de autenticación para acceder a otras aplicaciones desde el dispositivo. Cuando un PRT solicita acceso a la aplicación, Microsoft Entra ID confía en sus notificaciones MFA y dispositivo. Esto aumenta la resistencia al reducir los pasos para autenticar el dispositivo. Los usuarios no se enfrentan a múltiples solicitudes de MFA en el mismo dispositivo.

Consulte ¿Qué es un token de actualización principal?

Diagrama de una aplicación que llama a la plataforma de identidad de Microsoft, a través de una caché de tokens y un almacén de tokens, y al agente de autenticación en el dispositivo que ejecuta la aplicación.

MSAL admite la autenticación de agente. Más información:

Evaluación continua de acceso

La Evaluación continua de acceso (CAE) aumenta la seguridad y la resistencia de las aplicaciones con tokens de larga duración. Con CAE, un token de acceso se revoca basándose en eventos críticos y evaluación de directivas en lugar de en una duración de token breve. En el caso de algunas API de recursos, ya que el riesgo y la directiva se evalúan en tiempo real, CAE puede aumentar considerablemente la duración del token hasta 28 horas. MSAL actualiza tokens de larga duración.

Más información:

Si desarrolla API de recursos, vaya a openid.net para Señales compartidas: un marco de webhooks seguro.

Aumento de la resistencia de la autenticación y la autorización en las aplicaciones cliente que se desarrollan