Ressourcen und Bereiche

Microsoft Identity Platform verwendet ein bereichsorientiertes Modell für den Zugriff auf Ressourcen. Hier bezieht sich eine Ressource auf jede Anwendung, die ein Empfänger eines Zugriffstokens sein kann (z. B. MS Graph-API oder Ihre eigene Web-API), und ein Bereich (auch als "Berechtigung" bezeichnet) bezieht sich auf jeden Aspekt einer Ressource, die ein Zugriffstoken Rechte gewährt.

Anforderungen für Zugriffstoken in MSAL.js sind pro Ressource und pro Bereich(e) vorgesehen. Dies bedeutet, dass ein Zugriffstoken , das für Ressource A mit Bereich scp1angefordert wurde:

  • Kann nicht für den Zugriff auf Ressource A mit Bereich scp2verwendet werden und,
  • Kann nicht für den Zugriff auf Ressource B eines beliebigen Bereichs verwendet werden.

Der beabsichtigte Empfänger eines Zugriffstokens wird durch den aud Anspruch dargestellt. Falls der Wert für den aud Anspruch nicht mit dem URI der Ressourcen-APP-ID übereinstimmt, sollte das Token als ungültig betrachtet werden. Ebenso werden die Berechtigungen, die ein Zugriffstoken gewährt, durch den scp Anspruch dargestellt. Weitere Informationen finden Sie unter Zugriffstokenansprüche .

Standardbereiche

Standardmäßig fügt MSAL.js jeder Anfrage die Scopes openid, profile und offline_access hinzu. Diese Bereiche sind erforderlich, um ein Aktualisierungstoken und die ID-Tokenansprüche zu empfangen, die zum Auffüllen des Kontoobjekts mit den Informationen des Benutzers verwendet werden.

Arbeiten mit mehreren Ressourcen

Wenn Sie auf mehrere Ressourcen zugreifen müssen, initiieren Sie jeweils eine separate Tokenanforderung:

// "User.Read" stands as shorthand for "graph.microsoft.com/User.Read"
const graphToken = await msalInstance.acquireTokenSilent({
     scopes: [ "User.Read" ]
});
const customApiToken = await msalInstance.acquireTokenSilent({
     scopes: [ "api://<myCustomApiClientId>/My.Scope" ]
});

Denken Sie daran, dass Sie mehrere Bereiche für dieselbe Ressource anfordern können (z. B. User.ReadUser.Write für Calendar.ReadMS Graph-API).

const graphToken = await msalInstance.acquireTokenSilent({
     scopes: [ "User.Read", "User.Write", "Calendar.Read" ] // all MS Graph API scopes
});

Falls Sie in Ihrer Tokenanforderung versehentlich mehrere Ressourcen übergeben, wird das empfangene Token nur für die erste Ressource ausgegeben.

// you will only receive a token for MS GRAPH API's "User.Read" scope here
const myToken = await msalInstance.acquireTokenSilent({
     scopes: [ "User.Read", "api://<myCustomApiClientId>/My.Scope" ]
});

In Microsoft Entra ID werden die bereiche (Berechtigungen), die direkt für die Anwendungsregistrierung festgelegt werden, als statische Bereiche bezeichnet. Andere Bereiche, die nur innerhalb des Codes definiert sind, werden als dynamische Bereiche bezeichnet. Dies hat Auswirkungen auf die Anmeldemethoden (z. B. loginPopup, loginRedirect) und acquireToken (d. h. acquireTokenPopup, acquireTokenRedirect, acquireTokenSilent) von MSAL.js. Berücksichtigen Sie dabei Folgendes:

 const loginRequest = {
      scopes: [ "openid", "profile", "User.Read" ]
 };
 const tokenRequest = {
      scopes: [ "Mail.Read" ]
 };
 // will return an ID Token and an Access Token with scopes: "openid", "profile" and "User.Read"
 msalInstance.loginPopup(loginRequest);
 // will fail and fallback to an interactive method prompting a consent screen
 // after consent, the received token will be issued for "openid", "profile" ,"User.Read" and "Mail.Read" combined
 msalInstance.acquireTokenSilent(tokenRequest);

Im obigen Codeausschnitt wird der Benutzer aufgefordert, die Zustimmung einzuholen, sobald er sich authentifiziert und ein ID-Token und ein Zugriffstoken mit dem Bereich User.Readerhält. Wenn sie später ein ZugriffstokenUser.Readanfordern, werden sie nicht erneut zur Zustimmung aufgefordert (mit anderen Worten, sie können ein Token im Hintergrund erwerben).

Der Benutzer hat jedoch der Verwendung von Mail.Read während der Authentifizierungsphase nicht zugestimmt und wird daher bei der Anforderung eines Access Token für Mail.Read um Einwilligung gebeten. Das empfangene Token enthält alle zuvor zugestimmten Bereiche (für diese spezifische Ressource), daher die inkrementelle Zustimmung.

Betrachten Sie einen etwas anderen Fall:

 const loginRequest = {
      scopes: [ "openid", "profile", "User.Read" ],
      extraScopesToConsent: [ "api://<myCustomApiClientId>/My.Scope"]
 };
 const tokenRequest = {
      scopes: [ "Mail.Read" ]
 };
 const anotherTokenRequest = {
      scopes: [ "api://<myCustomApiClientId>/My.Scope" ]
 }
 // will return an ID Token and an Access Token with scopes: "openid", "profile" and "User.Read"
 msalInstance.loginPopup(loginRequest);
 // will fail with InteractionRequiredError due to lack of consent for "Mail.Read" scope. You should fallback to an interactive method in this case.
 msalInstance.acquireTokenSilent(tokenRequest);
 // will succeed and return an Access Token with scope "api://<myCustomApiClientId>/My.Scope"
 msalInstance.acquireTokenSilent(anotherTokenRequest);

Im obigen Codeausschnitt erhält der Benutzer, obwohl er sowohl den Bereichen User.Read als auch api://<myCustomApiClientId>/My.Scope zustimmt, nur ein Zugriffstoken für die MS Graph-API, gemäß dem Per-Resource-Per-Scope(s)-Prinzip. Da sie jedoch bereits zugestimmt haben api://<myCustomApiClientId>/My.Scope, können sie später ein Zugriffstoken für diese Ressource/diesen Bereich im Hintergrund erwerben.

In Microsoft Entra ID lebt die Zustimmung über die Lebensdauer der Anwendung hinaus. Dies bedeutet, dass beim Anfordern eines Zugriffstokens für eine Ressource alle Bereiche, denen Sie zuvor zugestimmt haben, zurückgegeben werden, unabhängig davon, welcher Bereich zum Zeitpunkt angefordert wurde. Mit anderen Worten: Wenn Sie heute User.Read und Mail.Read zustimmen und morgen eine neue Instanz Ihrer Anwendung ausführen, die nur für User.Read ein Zugriffstoken anfordert, erhalten Sie dennoch ein Token, das für beideUser.Read und Mail.Read ausgestellt wurde. Weitere Informationen finden Sie unter "Berechtigungen und Zustimmung".

  • Last updated on