Migración de MSAL v2.x a MSAL v3.x

Si no está familiarizado con MSAL, debería empezar aquí.

Si procede de MSAL v1.x, primero debe consultar esta guía para migrar a MSAL v2.x y, a continuación, siga los pasos siguientes.

Si procede de MSAL v2.x, puede seguir esta guía para actualizar el código para usar MSAL v3.x.

Cambios críticos

Creación de instancias de aplicaciones

En MSAL v2.x, ha creado una instancia de aplicación como se indica a continuación:

import { PublicClientApplication } from "@azure/msal-browser";

const msalConfig = {
    auth: {
        clientId: 'your_client_id'
    }
};

const msalInstance = new PublicClientApplication(msalConfig);

En MSAL v3.x, también debe inicializar el objeto de aplicación. Hay varias opciones a su disposición:

Opción 1

Cree una instancia de un PublicClientApplication objeto e inicialícelo después. La initialize función es asincrónica y debe resolverse antes de invocar otras API de MSAL.js.

import { PublicClientApplication } from "@azure/msal-browser";

const msalConfig = {
    auth: {
        clientId: 'your_client_id'
    }
};

const msalInstance = new PublicClientApplication(msalConfig);
await msalInstance.initialize();

Opción 2

Invoque el createPublicClientApplication método estático que devuelve un objeto inicializado PublicClientApplication . Tenga en cuenta que esta función es asincrónica.

import { PublicClientApplication } from "@azure/msal-browser";

const msalConfig = {
    auth: {
        clientId: 'your_client_id'
    }
};

const msalInstance = await PublicClientApplication.createPublicClientApplication(msalConfig);

Almacenamiento en caché basado en reclamaciones

En MSAL v2.x, agregar notificaciones a una solicitud dará como resultado un hash de la cadena de notificaciones solicitada que se agrega a la clave de caché de tokens de forma predeterminada. Esto implica que, de forma predeterminada, MSAL 2.x almacena en caché y compara los tokens en función de las declaraciones. En MSAL v3.x, este comportamiento ya no es el valor predeterminado. El comportamiento predeterminado de MSAL v3.x es ir a la red para actualizar un token cada vez que se solicitan notificaciones, independientemente de si el token se ha almacenado en caché anteriormente y sigue siendo válido. A continuación, después de ir a la red, el token recibido sobrescribe el token almacenado en caché en caso de que se ejecute una solicitud silenciosa sin notificaciones más adelante. Para habilitar el almacenamiento en caché basado en claims en MSAL v3.x y mantener el mismo comportamiento que en MSAL v2.x, los desarrolladores deben usar el indicador de configuración cacheOptions.claimsBasedCachingEnabled configurado como true en el objeto de configuración de la aplicación cliente:

const msalConfig = {
    auth: {
        ...
    },
    ...
    cache: {
        claimsBasedCachingEnabled: true
    }
}

const msalInstance = new msal.PublicClientApplication(msalConfig);
await msalInstance.initialize();

Todas las demás API son retrocompatibles con MSAL v2.x. Se recomienda echar un vistazo al ejemplo predeterminado para ver un ejemplo en funcionamiento de MSAL v3.0.

Cripto

MSAL v3.x deja de ser compatible con la criptografía nativa de IE11 window.msCrypto y con Microsoft Research JavaScript Cryptography Library (MSR crypto) window.msrCrypto en favor de la API criptográfica nativa del explorador window.crypto. Las opciones config.system.cryptoOptions criptográficas que se usaron para la criptografía MSR ya no se admiten también.

Cambios clave

Compatibilidad con navegadores

MSAL.js ya no admite los siguientes exploradores:

• IE 11
• Edge (heredado)

Dependencias de paquetes

La versión de Typescript se actualizó de 3.8.3 a 4.9.5.

Opciones del compilador

Las versiones del módulo y del destino se incrementaron de es6/es5 a es2020/es2020, respectivamente.

CDN

MSAL.js ya no se hospeda en una red CDN. Consulte este documento para obtener más detalles.