Abrufen von Zugriffstoken, die durch "Besitznachweis" geschützt sind

Um den Schutz von im Browser gespeicherten OAuth 2.0-Zugriffstoken gegen "Token replay" zu erhöhen, stellt MSAL ein Access Token Proof-of-Posession Authentifizierungsschema bereit. Access Token Proof-of-Possession AT PoPoder , ist ein Authentifizierungsschema, das die Zugriffstoken kryptografisch an den Browser und die Clientanwendung bindet, von der sie angefordert werden, d. h. sie können nicht von einer anderen Anwendung oder einem anderen Gerät verwendet werden.

Es ist wichtig zu verstehen, dass, damit AT PoP durchgängig funktioniert und das beabsichtigte Sicherheitsupgrade bereitstellt, sowohl der Autorisierungsdienst, der die Zugriffstoken ausgibt, als auch der Ressourcenserver, auf den diese Zugriff gewähren, AT PoP unterstützen müssen.

Bearer-Zugriffstoken vs. gebundenes Zugriffstoken (PoP)

Bearer-Zugriffstoken

Das von MSAL v2-APIs zurückgegebene Standardauthentifizierungsergebnis enthält eine accessToken Eigenschaft. Bei Verwendung mit dem Standardauthentifizierungsschema Bearer ist der Wert unter der accessToken Eigenschaft der vom Autorisierungsserver bereitgestellte Zugriffstokenschlüssel. Dieses Artefakt wird von MSAL zwischengespeichert und sollte Ressourcenanforderungen als Bearertoken im Anforderungsheader Authorization hinzugefügt werden.

Beispiel für die Verwendung eines Bearer-Access-Tokens:

// Using the Bearer scheme (default), acquireTokenRedirect returns an AuthenticationResult object containing the Bearer access token secret
const { accessToken } = await myMSALObj.acquireTokenRedirect(popTokenRequest);

// The bearer token secret is appended to the Authorization header
const headers = new Headers();
const authHeader = `Bearer ${accessToken}`; // The Bearer label is used in this header
headers.append("Authorization", authHeader);

Gebundenes Zugriffstoken

A.K.A PoP Token oder Signed HTTP Request. Wenn das POP Autorisierungsschema in einer MSAL-Tokenanforderung aktiviert ist, stellt der Autorisierungsserver weiterhin einen geheimen JSON-Webtokenzugriffstoken bereit, der wie ein Bearer Zugriffstoken aussieht, das MSAL ebenfalls zwischenspeichert. Der Hauptunterschied besteht darin, dass dieser Zugriffstokenschlüssel bei Verwendung des POP Schemas über einen asymmetrischen kryptografischen Keypair an den Browser des Benutzers gebunden wird.

Der geheime Zugriffstokenschlüssel wird in ein neues JSON-Webtoken eingeschlossen, das mit dem HMAC Hash-basierten Hashingalgorithmus (Hash-basierten Nachrichtenauthentifizierungscode) und dem privaten Schlüssel aus dem keypair signiert wird, den MSAL generiert, speichert und verwaltet. Das signierte JWT wird dann dem AuthorizationResult Objekt unter der accessToken Eigenschaft hinzugefügt und von der aufgerufenen MSAL v2-API zurückgegeben.

Sobald die Clientanwendung das zurückgegebene Authentifizierungsergebnis empfängt, kann sie den accessToken Wert aus dem Authentifizierungsergebnis extrahieren und dem Authorization Header einer poP-geschützten Ressourcenanforderung hinzufügen, wobei die PoP Bezeichnung anstelle der Bearer Bezeichnung verwendet wird.

Hinweis: Das signierte JWT (als signierte HTTP-Anforderung oder SHR bezeichnet) wird nie von MSAL zwischengespeichert. Jedes Mal, wenn eine MSAL v2-API aufgerufen wird, ruft MSAL entweder einen gültigen geheimen Rohzugriffstoken aus dem Cache ab oder fordert ein neues Zugriffstoken vom Autorisierungsserver an. MSAL signiert dann das besagte Zugriffstoken und gibt es im Authentifizierungsergebnis zurück.

Beispiel für die Verwendung eines gebundenen (PoP-)Zugriffstokens:

// Using the POP scheme (default), acquireTokenRedirect returns an AuthenticationResult object containing the Signed HTTP Request (PoP Token)
const { accessToken } = await myMSALObj.acquireTokenRedirect(popTokenRequest);

// The SHR is appended to the Authorization header
const headers = new Headers();
const authHeader = `PoP ${accessToken}`; // The PoP label is used in this header
headers.append("Authorization", authHeader);

Erstellen einer PoP-Tokenanforderung

Nachdem Sie den Autorisierungsdienst und den Ressourcenserver für die Zugriffstokenbindung bestimmt haben, können Sie Ihre MSAL-Authentifizierungs- und Autorisierungsanforderungsobjekte so konfigurieren, dass gebundene Zugriffstoken abgerufen werden, indem Sie ein Tokenanforderungsobjekt erstellen, das die poP-spezifischen Attribute des Zugriffstokens enthält. Alle folgenden Attribute sind im Anforderungsobjekt optional. AutorisierungScheme muss jedoch manuell auf "pop" festgelegt werden, um den Besitznachweis zu ermöglichen.

AT PoP-Anforderungsparameter

Hinweis: Obwohl dieses Dokument zeigt, wie eine shrNonce zum SignedHttpRequest hinzugefügt wird, wird das Muster zur Beschaffung des Server-Nonce hier nicht behandelt. Weitere Informationen zum Abrufen serverseitig generierter Nonces finden Sie in der SHR Server Nonce-Dokumentation.

Beispiel für die Umleitungsanforderung für den Tokenabruf

const popTokenRequest = {
    scopes: ["User.Read"],
    authenticationScheme: msal.AuthenticationScheme.POP,
    resourceRequestMethod: "POST",
    resourceRequestUri: "YOUR_RESOURCE_ENDPOINT",
    shrClaims: "{\"shrClaim1\": \"claimValue\"}",
    shrNonce: "NONCE_ACQUIRED_FROM_RESOURCE_SERVER"
}

Nachdem die Anforderung konfiguriert und POP als authenticationSchemefestgelegt wurde, kann sie an die acquireTokenRedirect MSAL v2-API gesendet werden.

const response = await myMSALObj.acquireTokenRedirect(popTokenRequest);

// Once a Pop Token has been acquired, it can be added on the authorization header of a resource request
const headers = new Headers();
const authHeader = `${response.tokenType} ${response.accessToken}`;

headers.append("Authorization", authHeader);

const options = {
    method: popTokenRequest.resourceRequestMethod,
    headers: headers
};

// After the request has been built and the POP access token has bee appended, the request can be executed using an API like "fetch"
fetch(endpoint, options)
    .then(response => response.json())
    .then(response => callback(response, endpoint))
    .catch(error => console.log(error));
});

Beispiel für eine automatische Anforderung für den Tokenabruf

Das stille Abrufen von PoP-Zugriffstoken erfordert dieselben Änderungen an der Tokenanforderungskonfiguration wie für die interaktiven acquireToken-APIs:

const silentPopTokenRequest = {
    scopes: ["User.Read"],
    authenticationScheme: msal.AuthenticationScheme.POP, // Default is "BEARER"
    resourceRequestMethod: "POST",
    resourceRequestUri: "YOUR_RESOURCE_ENDPOINT",
    shrClaims: "{\"shrClaim1\": \"claimValue\"}",
    shrNonce: "NONCE_ACQUIRED_FROM_RESOURCE_SERVER"
}

// Try to acquire token silently
const { accessToken } = await myMSALObj.acquireTokenSilent(silentPopTokenRequest).catch(async (error) => {
        console.log("Silent token acquisition failed.");
        if (error instanceof msal.InteractionRequiredAuthError) {
            // Fallback to interaction if silent call fails
            console.log("Acquiring token using redirect");
            myMSALObj.acquireTokenRedirect(silentPopTokenRequest);
        } else {
            console.error(error);
        }
    });

// Once a Pop Token has been acquired, it can be added on the authorization header of a resource request
const headers = new Headers();
const authHeader = `PoP ${accessToken}`;

headers.append("Authorization", authHeader);

const options = {
    method: popTokenRequest.resourceRequestMethod,
    headers: headers
};

// After the request has been built and the POP access token has bee appended, the request can be executed using an API like "fetch"
fetch(endpoint, options)
    .then(response => response.json())
    .then(response => callback(response, endpoint))
    .catch(error => console.log(error));
});

PoP-Schlüsselverwaltung

Das Authentifizierungsschema "Proof-of-Possession" basiert auf einem asymmetrischen kryptografischen Schlüsselpair, um das Zugriffstoken an den Browser des Benutzers zu binden. MSAL Browser generiert diesen Keypair, wenn zunächst ein Zugriffstoken vom Autorisierungsdienst angefordert und mithilfe von IndexedDB gespeichert wird. Dieses kryptografische Schlüsselpaar wird dann verwendet, um das SHR jedes Mal zu signieren, wenn das gebundene Zugriffstoken still angefordert wird.

Beim Aktualisieren eines gebundenen Zugriffstokens löscht MSAL das kryptografische Schlüsselpair, das beim Anfordern des abgelaufenen gebundenen Zugriffstokens generiert wurde, generiert einen neuen kryptografischen Schlüsselpair für das neue Zugriffstoken, und speichert den neuen Keypair im Keystore.

Erweiterte Funktion: Von der Anwendung verwaltetes kryptografisches Schlüsselpaar

Wenn Sie sich dafür entscheiden, Ihr eigenes kryptografisches Schlüsselpaar zu generieren, ermöglicht diese Funktion der Anwendung, popKid als Anforderungsparameter bereitzustellen. MSAL JS stellt sicher, dass der Token-Aussteller cnf in das Token einbettet, das ausgestellte Token jedoch unsigniert zurückgibt. Die Verantwortung, das Zugriffstoken zu signieren, bevor es an die Zielressource weitergeleitet wird, liegt bei der Anwendung.

Bitte beachten Sie außerdem, dass die verbleibenden PoP-Parameter mit Ausnahme von authenticationScheme nicht festgelegt werden dürfen, wenn Sie dieses Verhalten nutzen möchten.

Warum Zugriffstoken asynchron gespeichert werden

Die meisten MSAL-Anmeldedaten und Cacheelemente, wie z. B. ID Tokens, können synchron gespeichert und entfernt werden. Dies liegt daran, dass diese Cacheelemente entweder localStorage oder sessionStorage (die synchron bearbeitet werden können) gespeichert werden und keine Abhängigkeiten von anderen gespeicherten Elementen aufweisen, die asynchrone Zugriffsbeschränkungen aufweisen.

Im Gegensatz zu anderen Cacheelementen Access Tokens werden sie asynchron im Cache gespeichert. Der Grund dafür ist, dass im Fall eines Zugriffstokens, das an ein kryptografisches Schlüsselpaar gebunden ist, das in IndexedDB gespeichert ist, das Ersetzen des Zugriffstokens auch das Ersetzen des kryptografischen Schlüsselpaares umfasst. Da das Entfernen und Schreiben von Schlüsseln in IndexedDB asynchrone Vorgänge sind, wird damit zwangsläufig auch der Vorgang zum Speichern eines Zugriffstokens asynchron.

Codebeispiele

• JavaScript SPA- Erwerb von PoP-Token