Prostředky a obory

Microsoft identity platform využívá pro přístup k prostředkům model orientovaný na obor. V tomto případě prostředek odkazuje na libovolnou aplikaci, která může být příjemcem přístupového tokenu (například MS Graph API nebo vlastního webového rozhraní API) a obor (neboli "oprávnění") odkazuje na jakýkoli aspekt prostředku, který přístupový token uděluje práva.

Žádosti o přístupový token v MSAL.js jsou určené pro jednotlivé prostředky a rozsahy. To znamená, že přístupový token požadovaný pro prostředek A s rozsahem scp1:

  • nelze použít pro přístup k prostředku A s rozsahem scp2 a,
  • nelze použít pro přístup k prostředku B v libovolném rozsahu.

Zamýšlený příjemce přístupového tokenu je reprezentován aud deklarací identity. V případě, že hodnota aud deklarace neodpovídá identifikátoru URI ID APLIKACE prostředku, měl by být token považován za neplatný. Podobně jsou oprávnění, která přístupový token uděluje, vyjádřena nárokem scp. Další informace najdete v tématu Deklarace identity přístupového tokenu .

Výchozí obory

Ve výchozím nastavení MSAL.js přidá ke každému požadavku oprávnění openid, profile a offline_access. Tyto rozsahy oprávnění jsou vyžadovány k získání tokenu pro obnovení a atributů v ID tokenu, které se používají k naplnění objektu účtu informacemi o uživateli.

Práce s více zdroji

Pokud potřebujete získat přístup k více prostředkům, zahajte pro každý z nich samostatný požadavek na token:

// "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" ]
});

Mějte na paměti, že pro stejný prostředek můžete požádat o více rozsahů (např. User.Read, User.Write a Calendar.Read pro MS Graph API).

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

V případě, že v žádosti o token omylem předáte více prostředků, bude token, který obdržíte, vystaven pouze pro první prostředek.

// 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" ]
});

V Microsoft Entra ID se obory (oprávnění) nastavené přímo na registraci aplikace nazývají statické obory. Jiné obory, které jsou definovány pouze v kódu, se nazývají dynamické obory. To má dopad na metody login (tj. loginPopup, loginRedirect) a acquireToken (tj. acquireTokenPopup, acquireTokenRedirect, acquireTokenSilent) v knihovně MSAL.js. Rozmyslete si:

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

Ve výše uvedeném fragmentu kódu se uživateli zobrazí výzva k vyjádření souhlasu po ověření a přijetí tokenu ID a přístupového tokenu s oborem User.Read. Později, pokud požádá o přístupový token pro User.Read, nebudou znovu požádáni o souhlas (jinými slovy, mohou získat token bezobslužně).

Na druhé straně uživatel neudělil souhlas s Mail.Read fází ověřování, proto bude požádán o souhlas při vyžádání přístupového tokenu pro Mail.Read obor. Přijatý token bude obsahovat všechny dříve odsouhlasené obory (pro tento konkrétní prostředek), proto termín přírůstkový souhlas.

Zvažte trochu jiný případ:

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

Ve výše uvedeném fragmentu kódu uživatel, i když souhlasí s oběma oprávněními User.Read a api://<myCustomApiClientId>/My.Scope, obdrží přístupový token pouze pro rozhraní MS Graph API v souladu s principem jednoho prostředku pro každý rozsah oprávnění. Nicméně, protože již udělili souhlas s api://<myCustomApiClientId>/My.Scope, mohou později pro tento prostředek/rozsah získat přístupový tokenbez zásahu uživatele.

V Microsoft Entra ID žije souhlas nad rámec životnosti aplikace. To znamená, že když požádáte o přístupový token pro prostředek, vrátí se všechny obory, se kterými jste dříve souhlasili, bez ohledu na to, jaký rozsah byl v danou chvíli požadován. Jinými slovy, pokud souhlasíte s User.Read a Mail.Read dnes a spustíte novou instanci vaší aplikace, která zítra požádá pouze o přístupový tokenUser.Read, stále obdržíte token vystavený pro obojíUser.Read i Mail.Read. Další informace najdete v tématu Oprávnění a Souhlas.

  • Last updated on