Risorse e ambiti

Microsoft Identity Platform usa un modello incentrato sugli ambiti per accedere alle risorse. In questo caso, una risorsa fa riferimento a qualsiasi applicazione che può essere un destinatario di un token di accesso (ad esempio MS API Graph o la propria API Web) e un ambito (noto anche come "autorizzazione") fa riferimento a qualsiasi aspetto di una risorsa concessa da un token di accesso.

Le richieste di token di accesso in MSAL.js sono concepite per essere per risorsa e per ambito/i. Ciò significa che un token di accesso richiesto per la risorsa A con ambito scp1:

  • non può essere usato per accedere alla risorsa A con ambito scp2, e,
  • non può essere usato per accedere alla risorsa B di qualsiasi ambito.

Il destinatario previsto di un token di accesso è rappresentato dall'attestazione aud . Nel caso in cui il valore dell'attestazione aud non corrisponda all'URI ID APP della risorsa, il token deve essere considerato non valido. Analogamente, le autorizzazioni concesse da un token di accesso sono rappresentate dall'attestazione scp . Per altre informazioni, vedere Attestazioni del token di accesso .

Ambiti predefiniti

Per impostazione predefinita, MSAL.js aggiungerà gli scope openid, profile e offline_access a ogni richiesta. Questi ambiti sono necessari per ricevere un token di aggiornamento e le attestazioni del token ID usate per popolare l'oggetto account con le informazioni dell'utente.

Uso di più risorse

Quando è necessario accedere a più risorse, avviare una richiesta di token separata per ognuna:

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

Tenere presente che è possibile richiedere più ambiti per la stessa risorsa ( ad esempio User.Read, User.Write e Calendar.Read per MS API Graph).

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

Se si passano erroneamente più risorse nella richiesta di token, il token ricevuto verrà emesso solo per la prima risorsa.

// 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, gli ambiti (autorizzazioni) impostati direttamente nella registrazione dell'applicazione sono denominati ambiti statici. Altri ambiti definiti solo all'interno del codice sono denominati ambiti dinamici. Ciò ha implicazioni sui metodi login (ad esempio loginPopup, loginRedirect) e acquireToken (ad esempio acquireTokenPopup, acquireTokenRedirect, acquireTokenSilent) di MSAL.js. Tenere in considerazione:

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

Nel frammento di codice precedente, all'utente verrà richiesto il consenso dopo l'autenticazione e la ricezione di un token ID e di un token di accesso con l'ambito User.Read. In seguito, se richiedono un token di accesso per User.Read, non verrà chiesto di nuovo il consenso (in altre parole, possono acquisire un token in modo invisibile all'utente).

D'altra parte, l'utente non ha acconsentito a Mail.Read nella fase di autenticazione; pertanto, gli verrà richiesto di fornire il consenso quando viene richiesto un token di accesso per lo scope Mail.Read. Il token ricevuto conterrà tutti gli scope per i quali è già stato fornito il consenso (per quella specifica risorsa), da cui il termine consenso incrementale.

Si consideri un caso leggermente diverso:

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

Nel frammento di codice precedente, anche se l'utente acconsente a entrambi gli ambiti User.Read e api://<myCustomApiClientId>/My.Scope, riceverà solo un token di accesso per MS API Graph, in conformità al principio per-risorsa-per-ambito. Tuttavia, poiché hanno già acconsentito a api://<myCustomApiClientId>/My.Scope, possono ottenere un Access Token per tale risorsa/ambito senza interazione dell'utente successivamente.

In Microsoft Entra ID il consenso supera la durata dell'applicazione. Ciò significa che, quando si richiede un token di accesso per una risorsa, tutti gli ambiti a cui è stato precedentemente concesso il consenso per tale risorsa verranno restituiti, indipendentemente dall'ambito richiesto al momento. In altre parole, se oggi acconsenti a User.Read e Mail.Read e domani esegui una nuova istanza dell'applicazione che richiede un token di accesso solo per User.Read, riceverai comunque un token emesso per entrambiUser.Read e Mail.Read. Per altre informazioni, vedere Autorizzazioni e consenso.

  • Last updated on