Almacenamiento en caché de tokens en el nodo MSAL

Cuando el nodo MSAL adquiere un token, lo almacena en caché en memoria para su uso futuro. MSAL Node gestiona el ciclo de vida del token y su renovación. API como acquireTokenSilent() recuperan tokens de acceso de la memoria caché para una cuenta determinada:

MSAL no expone tokens de actualización por motivos de seguridad. Consulte las preguntas más frecuentes sobre cómo obtener los tokens de actualización.

Uso de secretos de cliente de forma segura

Los secretos de cliente nunca se deben codificar de forma dura. El paquete npm de dotenv se puede usar para almacenar secretos en un archivo .env (ubicado en el directorio raíz del proyecto) que se debe incluir en .gitignore para evitar cargas accidentales de los secretos.

const msal = require('@azure/msal-node');
require('dotenv').config(); // process.env now has the values defined in a .env file

// Create msal application object
const cca = new msal.ConfidentialClientApplication({
    auth: {
        clientId: "Enter_the_Application_Id_Here", // e.g. "00001111-aaaa-2222-bbbb-3333cccc4444" (guid)
        authority: "https://login.microsoftonline.com/Enter_the_Tenant_Info_Here", // e.g. "common" or your tenantId (guid)
        clientSecret: process.env.clientSecret // obtained during app registration
    }
});

/**
* acquireToken* APIs return an account object containing the "homeAccountId"
* you should keep a record of this in your app and use it later on when calling acquireTokenSilent
*/
const someUserHomeAccountId = "Enter_User_Home_Account_Id";

const msalTokenCache = cca.getTokenCache();
const account = await msalTokenCache.getAccountByHomeId(someUserHomeAccountId);

const silentTokenRequest = {
    account: account,
    scopes: ["User.Read"],
};

cca.acquireTokenSilent(silentTokenRequest).then((response) => {
    // do something with response
}).catch((error) => {
    // catch and handle errors
});

En un entorno de producción, probablemente querrá serializar y persistir la caché de tokens. Según el tipo de aplicación, puede:

  • Aplicaciones de escritorio, aplicaciones de consola (aplicaciones de clientes públicos (PCA)):
    • Use MSAL Node Extensions, que proporciona soluciones de persistencia y de cifrado en reposo en Windows, Linux y Mac OS.
  • Aplicaciones web, API web, aplicaciones demonio (aplicaciones cliente confidenciales (CCA)):
    • La caché de tokens en memoria de MSAL no es escalable en entornos de producción. Utilice el patrón de almacenamiento en caché distribuido de tokens para persistir la caché en el entorno de almacenamiento que elija (Redis, MongoDB, bases de datos SQL, etc.; tenga en cuenta que puede usarlos de forma conjunta, p. ej., una caché en memoria similar a Redis como primera capa de persistencia y una base de datos SQL como segunda capa de persistencia, más estable).

Caché en memoria

MSAL mantiene una caché en memoria. La caché en memoria es representativa del estado de la caché de la aplicación. La vida útil de la caché en memoria es la misma que la del objeto de aplicación MSAL. Si el proceso mediante MSAL se reinicia, la memoria caché se borra cuando finaliza el ciclo de vida del proceso. Si la caché en memoria está vacía y no hay ninguna caché persistente para restaurar la memoria caché, los usuarios tendrán que volver a autenticarse. Cuando esto sucede, si el usuario todavía tiene una sesión activa con Microsoft Entra ID, es posible que vuelva a autenticarse sin avisos, pero esto sigue degradando la experiencia del usuario. Los escenarios de servicio a servicio (es decir, el flujo de credenciales de cliente y el flujo de concesión en nombre de otro) también se ven afectados, porque obtener un token de Microsoft Entra ID implica realizar peticiones HTTP y es mucho más lento que obtener un token de la caché.

Tenga en cuenta que la caché en memoria no es escalable para las aplicaciones del lado servidor y el rendimiento se degradará después de mantener unos 100 tokens en caché. Para escenarios de aplicaciones web y API web, esto se aproxima a servir a unos 100 usuarios. En el caso de escenarios de aplicación demonio que usan credenciales de cliente concedidas para llamar a otras aplicaciones, esto significa unos 100 inquilinos. Consulte el rendimiento siguiente para obtener más información.

⚠️ Se recomienda conservar la memoria caché con cifrado para todas las aplicaciones de producción, tanto para la seguridad como para la durabilidad deseada de la caché. Si decide no conservar la memoria caché, la interfaz de TokenCache sigue estando disponible para acceder a las entidades almacenadas en caché.

Caché persistente

MsAL Node desencadena eventos cuando se accede a la caché en memoria y las aplicaciones pueden elegir si conservar la memoria caché (consulte: TokenCacheContext) (por ejemplo, en un archivo, una base de datos SQL, etc.). Esto constituye dos acciones:

  1. Cargar la caché desde el almacenamiento persistente en la memoria de MSAL antes de acceder a la caché
  2. Si la memoria caché en memoria ha cambiado desde el último acceso, guarde la memoria caché de nuevo en el almacenamiento persistente.

Para conservar la memoria caché, MSAL acepta un complemento de caché personalizado en la configuración. Este complemento debe implementar la interfaz ICachePlugin :

interface ICachePlugin {
    beforeCacheAccess: (tokenCacheContext: TokenCacheContext) => Promise<void>;
    afterCacheAccess: (tokenCacheContext: TokenCacheContext) => Promise<void>;
}

Una implementación básica de la ICachePlugin interfaz podría ser la siguiente (consulte también el rendimiento y la seguridad si va a compilar una aplicación del lado servidor):

class MyCachePlugin implements ICachePlugin {
    private client: ICacheClient;

    constructor(client: ICacheClient) {
        this.client = client; // client object to access the persistent cache
    }

    public async beforeCacheAccess(cacheContext: TokenCacheContext): Promise<void> {
        const cacheData = await this.client.get(); // get the cache from persistence
        cacheContext.tokenCache.deserialize(cacheData); // deserialize it to in-memory cache
    }

    public async afterCacheAccess(cacheContext: TokenCacheContext): Promise<void> {
        if (cacheContext.cacheHasChanged) {
            await this.client.set(cacheContext.tokenCache.serialize()); // deserialize in-memory cache to persistence
        }
    }
}
  • Si va a desarrollar una aplicación cliente pública, las extensiones de nodo de MSAL lo controlan por usted.
  • Si va a desarrollar una aplicación cliente confidencial, debe conservar la caché a través de un servicio independiente, ya que una única instancia de caché por servidor no es adecuada para un entorno en la nube con muchos servidores e instancias de aplicación.

Se recomienda encarecidamente cifrar la caché de tokens al conservarla en el disco. Para las aplicaciones cliente públicas, esto se ofrece de serie con MSAL Node Extensions. Sin embargo, para los clientes confidenciales, es responsable de diseñar una solución de cifrado adecuada.

Rendimiento y seguridad

En las aplicaciones cliente públicas, las extensiones de nodo de MSAL garantizan el rendimiento y la seguridad.

En las aplicaciones cliente confidenciales que administran usuarios (aplicaciones web que permiten a los usuarios iniciar sesión y llamar a API web, y API web que llaman a API web descendentes), puede haber muchos usuarios activos simultáneamente en una aplicación determinada. Nuestra recomendación es serializar un blob en caché (consulte CacheRecord) por usuario. Esto ayudaría a escalar la memoria caché en un sistema distribuido. Use una clave para crear particiones en la memoria caché (es decir, clave de partición), como:

  • Para aplicaciones web: <userObjectId>.<tenantId> (es decir, homeAccountId)
  • Para las aplicaciones demonio multiinquilino mediante la concesión de credenciales de cliente: <clientId>.<tenantId>
  • Para las API web que llaman a otras API web mediante OBO: hash del token de acceso entrante (es decir, oboAssertion), el token que posteriormente se intercambiará por un token de OBO.

⚠️ Asegúrese de ver el rendimiento para obtener más información sobre cómo supervisar el uso y evitar un rendimiento deficiente.

Aplicaciones web

Dado que las aplicaciones web están orientadas al usuario y a menudo dependen de sesiones para realizar un seguimiento de cada usuario, la clave de partición adecuada para el almacenamiento en caché se almacena a menudo dentro de los datos de sesión y debe recuperarse antes de que se pueda realizar la búsqueda en caché. Para ayudar con esto, MSAL Node proporciona la clase DistributedCachePlugin , que implementa ICachePlugin. Una instancia de DistributedCachePlugin requiere:

  • una interfaz de cliente (ICacheClient), que implementa las operaciones get y set en el servidor de persistencia (Redis, MySQL, etc.).
  • un administrador de particiones (IPartitionManager), para leer y escribir en la memoria caché con respecto a un identificador de sesión determinado.

Consulte la aplicación web mediante DistributedCachePlugin para obtener una implementación de ejemplo.

Consulte también

Consulte los ejemplos siguientes para obtener más información sobre cómo controlar el almacenamiento en caché en aplicaciones de nodo de MSAL:

  • Last updated on