Jogkivonatok gyorsítótárazása az MSAL Node-ban

Amikor az MSAL Node tokent kér le, azt a memóriában gyorsítótárazza későbbi használatra. Az MSAL Node kezeli Ön helyett a token élettartamát és megújítását. Az API-k például acquireTokenSilent() lekérik a hozzáférési jogkivonatokat egy adott fiók gyorsítótárából:

Az MSAL biztonsági okokból nem teszi közzé a frissítési jogkivonatokat. A refresh tokenek beszerzésével kapcsolatos tudnivalókért tekintse meg a GYIK részt.

Titkos ügyfélkódok biztonságos használata

Az ügyfél titkos kódját soha nem szabad szigorúan kódolni. A dotenv npm-csomag segítségével titkos kulcsokat tárolhat egy .env fájlban (amely a projekt gyökérkönyvtárában található), amelyet a .gitignore-ban kell elhelyezni a titkos kódok véletlen feltöltésének megakadályozása érdekében.

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
});

Éles környezetben valószínűleg szerializálni és őrizni szeretné a jogkivonat-gyorsítótárat. Az alkalmazás típusától függően a következőt teheti:

  • Asztali alkalmazások, konzolalkalmazások (nyilvános ügyfélalkalmazások (PCA)):
    • Használja a MSAL Node Extensions szolgáltatást, amely Windows, Linux és macOS rendszeren perzisztenciai és tárolt állapotban történő titkosítási megoldásokat biztosít.
  • Webalkalmazások, webes API-k, démonalkalmazások (bizalmas ügyfélalkalmazások (CCA)):
    • Az MSAL memóriában tárolt tokengyorsítótára nem skálázódik éles környezetben. Használja az elosztott token-gyorsítótárazási mintát a gyorsítótárnak az Ön által választott tárolási környezetben való megőrzéséhez (Redis, MongoDB, SQL-adatbázisok stb. – tartsa szem előtt, hogy ezeket együtt is használhatja pl. egy Redis-szerű memóriagyorsítótárat a perzisztencia első rétegeként, valamint egy SQL-adatbázist második, stabilabb perzisztenciarétegként)

Memóriabeli gyorsítótár

Az MSAL memórián belüli gyorsítótárat tart fenn. A memóriabeli gyorsítótár az alkalmazásgyorsítótár állapotára jellemző. A memóriabeli gyorsítótár élettartama megegyezik az MSAL-alkalmazásobjektum élettartamával. Ha az MSAL-t használó folyamat újraindul, a gyorsítótár törlődik, amikor a folyamat életciklusa befejeződik. Ha a memóriában lévő gyorsítótár üres, és nincs perzisztens gyorsítótár, amelyből a gyorsítótár visszaállítható, a felhasználóknak újra kell hitelesíteniük magukat. Amikor ez megtörténik, ha a felhasználónak továbbra is aktív munkamenete van a Microsoft Entra ID-val, előfordulhat, hogy mindenféle felszólítás nélkül újra hitelesül, ez azonban akkor is rontja a felhasználói élményt. A szolgáltatások közötti forgatókönyvek (vagyis az ügyfél-hitelesítő adatokra épülő folyamat és a meghatalmazotti folyamat) szintén problémásak, mert a token Microsoft Entra ID-ból való lekérése HTTP-kéréseket igényel, és sokkal lassabb, mint a token gyorsítótárból való lekérése.

Vegye figyelembe, hogy a memóriabeli gyorsítótár nem méretezhető a kiszolgálóoldali alkalmazások számára, és a teljesítmény csökken, miután néhány 100 tokent tárolt a gyorsítótárban. Webalkalmazások és webes API-forgatókönyvek esetén ez körülbelül néhány 100 felhasználó kiszolgálását szolgálja ki. A démonalkalmazás-forgatókönyvek esetében, amelyek ügyfél-hitelesítő adatokat adnak meg más alkalmazások meghívásához, ez néhány 100 bérlőt jelent. További információért tekintse meg az alábbi teljesítményt .

⚠️ Javasoljuk a gyorsítótár tartós tárolásáttitkosítással minden éles alkalmazás esetében, mind a biztonság, mind a kívánt gyorsítótár-megőrzési idő érdekében. Ha úgy dönt, hogy nem tartja meg a gyorsítótárat, a TokenCache felület továbbra is elérhető a gyorsítótárazott entitások eléréséhez.

Perzisztens gyorsítótár

Az MSAL-csomópont aktiválja az eseményeket a memóriában lévő gyorsítótár elérésekor, és az alkalmazások eldönthetik, hogy megőrzik-e a gyorsítótárat (lásd: TokenCacheContext) (például egy fájlra, egy SQL-adatbázisra stb.). Ez két műveletből áll:

  1. A gyorsítótár elérése előtt töltse be azt a perzisztens tárolóból az MSAL memóriájába
  2. Ha a memóriabeli gyorsítótár megváltozott a legutóbbi hozzáférés óta, mentse a gyorsítótárat a megőrzése érdekében

A gyorsítótár megőrzéséhez az MSAL egy egyéni gyorsítótár beépülő modult fogad el a konfigurációban. Ennek a beépülő modulnak implementálnia kell az ICachePlugin felületet:

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

A felület alapszintű implementációja ICachePlugin a következő lehet (lásd még a teljesítményt és a biztonságot , ha kiszolgálóoldali alkalmazást hoz létre):

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
        }
    }
}
  • Ha nyilvános ügyfélalkalmazást fejleszt, az MSAL Node Extensions kezeli ezt Az Ön számára.
  • Ha bizalmas ügyfélalkalmazást fejleszt, a gyorsítótárat egy külön szolgáltatáson keresztül kell őriznie, mivel egyetlen kiszolgálónkénti gyorsítótárpéldány nem alkalmas több kiszolgálót és alkalmazáspéldányt tartalmazó felhőkörnyezetben.

Határozottan javasoljuk a tokengyorsítótár titkosítását, amikor azt lemezen tárolja. Nyilvános kliensalkalmazások esetén ez alapértelmezetten elérhető az MSAL Node Extensions használatával. A bizalmas ügyfelek esetében azonban Ön felelős a megfelelő titkosítási megoldás kialakításáért.

Teljesítmény és biztonság

Nyilvános ügyfélalkalmazásokban az MSAL csomópontbővítmények biztosítják a teljesítményt és a biztonságot.

A felhasználókat kezelő bizalmas ügyfélalkalmazások (a felhasználókat bejelentkező és webes API-kat hívó webalkalmazások, valamint az alsóbb rétegbeli webes API-kat hívó webes API-k) esetében számos felhasználó lehet aktív egyidejűleg egy adott alkalmazás esetében. Javasoljuk, hogy felhasználónként egy gyorsítótár-blobot szerializáljon (lásd : CacheRecord). Ez segíthet a gyorsítótár elosztott rendszerek közötti skálázásában. Használjon egy kulcsot a gyorsítótár particionálásához (pl.partíciókulcs), például:

  • Webalkalmazások esetén: <userObjectId>.<tenantId> (azaz homeAccountId)
  • Több-bérlős démonalkalmazások esetén az ügyfél hitelesítő adatainak megadása: <clientId>.<tenantId>
  • Más webes API-kat OBO használatával meghívó webes API-k esetén: a bejövő hozzáférési token hash-e (azaz oboAssertion) – az a token, amelyet később OBO-tokenre cserélnek

⚠️ Győződjön meg arról, hogy a teljesítmény további információt nyújt a használat monitorozásáról és a gyenge teljesítmény elkerüléséről.

Webalkalmazások

Mivel a webalkalmazások felhasználói elérésűek, és gyakran munkamenetekre támaszkodnak, hogy nyomon kövessék az egyes felhasználókat, a gyorsítótárazáshoz szükséges partíciókulcsot gyakran a munkamenet adatai tárolják, és le kell kérni a gyorsítótár-keresés előtt. Ennek érdekében az MSAL Node biztosítja az ElosztottCachePlugin osztályt, amely implementálja az ICachePlugin osztályt. A(z) DistributedCachePlugin egy példányához a következőkre van szükség:

  • egy ügyféloldali felület (ICacheClient), amely implementálja get és set műveletet végez a perzisztenciakiszolgálón (Redis, MySQL stb.).
  • egy partíciókezelő (IPartitionManager), amely egy adott munkamenet-azonosítóval kapcsolatos olvasást és írást biztosít a gyorsítótárba.

A mintamegvalósításhoz lásd a DistributedCachePlugint használó webalkalmazást.

Lásd még

Az alábbi mintákból további információkat tudhat meg arról, hogyan kezelje a gyorsítótárazást az MSAL Node-alkalmazásokban:

  • Last updated on