Konten im MSAL-Browser

Dies ist die plattformspezifische Kontendokumentation für die @azure/msal-browser Bibliothek, die die folgenden APIs für den Zugriff auf zwischengespeicherte Konten bereitstellt:

• getAllAccounts(): gibt alle Konten zurück, die sich derzeit im Cache befinden. Unterstützt einen optionalen Filter, um einen bestimmten Satz von Konten zurückzugeben. Eine Anwendung muss ein Konto auswählen, um Token im Hintergrund zu erwerben.
• getAccount(): gibt das erste zwischengespeicherte Konto zurück, das dem übergebenen Filter entspricht. Die Reihenfolge, in der Konten aus dem Cache gelesen werden, ist willkürlich und es gibt keine Garantie, dass das erste Konto in der gefilterten Liste für alle zwei Aufrufe getAccountidentisch ist. Wie weiter unten erläutert, bietet die Erhöhung der Anzahl von Filterattributen genauere Übereinstimmungen.

Account Filter-Objekt

Die AccountFilter-Typdokumentation listet die Eigenschaften auf, die zum Filtern von Konten verwendet und kombiniert werden können.

Die folgenden getAccountBy APIs sind veraltet. Verwenden getAccount() Sie stattdessen ein entsprechendes Filterobjekt:

• getAccountByHomeId(): verwenden Sie getAccount({ homeAccountId }) stattdessen.
• getAccountByLocalId(): verwenden Sie getAccount({ localAccountId }) stattdessen.
• getAccountByUsername(): verwenden Sie getAccount({ username }) stattdessen.

Es folgt ein Verwendungsbeispiel, das diese APIs abdeckt:

let homeAccountId = null; // Initialize global accountId (can also be localAccountId or username) used for account lookup later, ideally stored in app state

// This callback is passed into `acquireTokenPopup` and `acquireTokenRedirect` to handle the interactive auth response
function handleResponse(resp) {
    if (resp !== null) {
        homeAccountId = resp.account.homeAccountId; // alternatively: resp.account.homeAccountId or resp.account.username
    } else {
        const currentAccounts = myMSALObj.getAllAccounts();
        if (currentAccounts.length < 1) { // No cached accounts
            return;
        } else if (currentAccounts.length > 1) { // Multiple account scenario
            // Add account selection code here
            homeAccountId = ...
        } else if (currentAccounts.length === 1) {
            homeAccountId = currentAccounts[0].homeAccountId; // Single account scenario
        }
    }
}

Jetzt können Kontoeigenschaften wie: homeAccountId, localAccountIdund username können verwendet werden, um das zwischengespeicherte Konto nachzuschlagen, bevor ein Token im Hintergrund abgerufen wird:

// This method attempts silent token acquisition and falls back on acquireTokenPopup
async function getTokenPopup(request, homeAccountId) {
    // In this case, accounts are filtered by homeAccountId, but more attributes can be added to refine the search and increase the precision of the account filter
    const accountFilter = {
        homeAccountId: homeAccountId,
    };
    request.account = myMSALObj.getAccount(accountFilter);
    return await myMSALObj.acquireTokenSilent(request).catch(async (error) => {
        // Handle error
        return await myMSALObj.acquireTokenPopup(request);
    });
}

Filtern nach Anmeldehinweisen

Ab diesem @azure/msal-browser@3.2.0Grund können alle Anmeldehinweiswerte verwendet werden, um nach Konten zu suchen und zu filtern. Um nach Anmeldehinweisen zu filtern, vergleicht MSAL den loginHint Wert im AccountFilter Objekt mit den folgenden Kontoattributen (in Reihenfolge der Rangfolge), um nach Übereinstimmungen zu suchen:

• login_hint ID-Tokenanspruch
• username Account-Eigenschaft
• upn ID-Tokenanspruch

Verwenden des login_hint Anspruchs

const accountFilter = {
    loginHint: previouslyObtainedIdTokenClaims.login_hint;
};
request.account = myMSALObj.getAccount(accountFilter);
return await myMSALObj.acquireTokenSilent(request).catch(async (error) => {
    // Handle error
    return await myMSALObj.acquireTokenPopup(request);
});

Verwenden von "Benutzername"

Übergeben username als loginHint

const accountUsername = userProfile.username;
const accountFilter = {
    loginHint: accountUsername;
};
request.account = myMSALObj.getAccount(accountFilter);
return await myMSALObj.acquireTokenSilent(request).catch(async (error) => {
    // Handle error
    return await myMSALObj.acquireTokenPopup(request);
});

Übergeben username als username

const accountUsername = userProfile.username;
const accountFilter = {
    username: accountUsername;
};
request.account = myMSALObj.getAccount(accountFilter);
return await myMSALObj.acquireTokenSilent(request).catch(async (error) => {
    // Handle error
    return await myMSALObj.acquireTokenPopup(request);
});

Verwenden des upn Anspruchs

const accountFilter = {
    loginHint: previouslyObtainedIdTokenClaims.upn;
};
request.account = myMSALObj.getAccount(accountFilter);
return await myMSALObj.acquireTokenSilent(request).catch(async (error) => {
    // Handle error
    return await myMSALObj.acquireTokenPopup(request);
});

Aktive Konto-APIs

Die @azure/msal-browser Bibliothek bietet außerdem zwei bequeme APIs, mit denen Sie nachverfolgen können, welches Konto derzeit "aktiv" ist und für Tokenanforderungen verwendet werden sollte.

• getActiveAccount(): Gibt das aktuelle aktive Konto zurück.
• setActiveAccount(): Empfängt ein Kontoobjekt und legt es als aktives Konto fest.

Die Entscheidung, welches Konto zum Abrufen von Token verwendet werden soll, ist jedoch von der App abhängig, nachdem Sie bestimmt haben, welches Konto Sie verwenden möchten, rufen Sie einfach die setActiveAccount() API mit dem ausgewählten Kontoobjekt auf. Alle acquireTokenOder loginssoSilent Anrufe verwenden jetzt standardmäßig das aktive Konto, wenn in der einzelnen Anforderung kein anderes Konto angegeben ist. Um das derzeit aktive Konto zu löschen, können Sie anrufen setActiveAccount(null).

function login() {
    return myMsalObj.loginPopup().then((response) => {
        // After a successful login set the active account to be the user that just logged in
        myMsalObj.setActiveAccount(response.account);
    });
}

function getAccessToken() {
    // Providing an account in the token request is not required if there is an active account set
    return myMsalObj.acquireTokenSilent({ scopes: ["User.Read"] });
}

Hinweis: Ab Version 2.16.0 wird das aktive Konto am in Ihrer PublicClientApplication Instanz konfigurierten Cachespeicherort gespeichert. Wenn Sie eine frühere Version verwenden, wird das aktive Konto im Arbeitsspeicher gespeichert und muss daher bei jedem Seitenladevorgang zurückgesetzt werden.

Geschachtelte App-Authentifizierung

Für NAA-Anwendungen setActiveAccount() und getActiveAccount() sind NO-OP APIs. Obwohl Benutzer aktive Konten festlegen und abrufen können, werden sie aktiv ignoriert, da für die NAA-Anwendung immer ein Konto erwartet wird und das Konto von der Hostanwendung bereitgestellt accountContextwird. In Zukunft, wenn mehrere Konten über die Hubs hinweg unterstützt werden, wird dieses Verhalten voraussichtlich geändert.

Hinweise

• Das aktuelle Msal-Browser-Standardbeispiel verfügt über ein Arbeitsszenario für ein einzelnes Konto.
• Wenn Sie über ein Szenario mit mehreren Konten verfügen, ändern Sie das Beispiel (in handleResponse()) so, dass alle zwischengespeicherten Konten aufgeführt werden, und wählen Sie ein bestimmtes Konto aus.
• Wenn eine Anwendung ein Konto basierend auf dem usernameabrufen möchte, muss es die username (aus der Antwort einer login API für einen bestimmten Benutzer) vor der Verwendung des username Filters in der getAccount() API speichern.
• getAllAccounts() gibt mehrere Konten zurück, wenn Sie mehrere interaktive Tokenanforderungen gestellt haben und der Benutzer in zwei oder mehr dieser Interaktionen unterschiedliche Konten ausgewählt hat. Möglicherweise müssen Sie das interaktive AcquireToken oder die Anmelde-API übergeben oder prompt: "login" an die Anmelde-API übergebenprompt: "select_account", damit Microsoft Entra ID den Kontoauswahlbildschirm nach der ersten Interaktion anzeigen können.
• Die Konto-APIs geben den lokalen Kontostatus zurück und geben nicht unbedingt den Serverstatus wieder. Sie geben Konten zurück, die sich zuvor mit MSAL.js bei dieser App angemeldet haben, und die Serversitzung ist möglicherweise noch aktiv.
• Zwei apps, die in verschiedenen Domänen gehostet werden, teilen den Kontostatus nicht, da der Browserspeicher von der Domäne segementiert wird.
• getAllAccounts() ist nicht bestellt und ist nicht garantiert, dass sie sich in mehreren Anrufen in derselben Reihenfolge befinden.
• Jeder erfolgreiche Aufruf eines AcquireTokens oder einer Anmelde-API gibt genau ein Konto zurück.