Recursos y ámbitos

Plataforma de identidad de Microsoft emplea un modelo centrado en el ámbito para acceder a los recursos. Aquí, un recurso hace referencia a cualquier aplicación que pueda ser un destinatario de un token de acceso (como MS Graph API o su propia API web) y un ámbito (también conocido como "permiso") hace referencia a cualquier aspecto de un recurso al que un token de acceso concede derechos.

Las solicitudes de token de acceso en MSAL.js están destinadas a ser por recurso y por ámbito(s). Esto significa que un token de acceso solicitado para el recurso A con ámbito scp1:

  • no se puede usar para acceder al recurso A con el ámbito scp2, y ,
  • no se puede usar para acceder al recurso B de ningún ámbito.

El destinatario previsto de un token de acceso se representa mediante la aud notificación; en caso de que el valor de la aud notificación no coincida con el URI del identificador de aplicación del recurso, el token debe considerarse no válido. Del mismo modo, los permisos que concede un Access Token están representados por la declaración scp. Consulte Notificaciones de token de acceso para obtener más información.

Ámbitos predeterminados

De forma predeterminada, MSAL.js agregará los ámbitos openid, profile y offline_access a cada solicitud. Estos ámbitos son necesarios para recibir un token de actualización y las reclamaciones del token de identificación que se utilizan para rellenar el objeto de cuenta con la información del usuario.

Trabajar con varios recursos

Cuando tenga que acceder a varios recursos, inicie una solicitud de token independiente para cada uno:

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

Tenga en cuenta que puede solicitar varios ámbitos para el mismo recurso (por ejemploUser.Read, , User.Write y Calendar.Read para MS Graph API).

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

En caso de que pase erróneamente varios recursos en la solicitud de token, el token que recibirá solo se emitirá para el primer recurso.

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

En Microsoft Entra ID, los ámbitos (permisos) establecidos directamente en el registro de aplicaciones se denominan ámbitos estáticos. Otros ámbitos que solo se definen dentro del código se denominan ámbitos dinámicos. Esto tiene implicaciones en los métodos login (es decir, loginPopup, loginRedirect) y acquireToken (es decir, acquireTokenPopup, acquireTokenRedirect, acquireTokenSilent) de MSAL.js. Piense en lo siguiente:

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

En el fragmento de código anterior, se le pedirá al usuario su consentimiento una vez que se autentique y reciba un token de identificador y un token de acceso con el ámbito .User.Read Más adelante, si solicitan un token de acceso para User.Read, no se les pedirá de nuevo consentimiento (es decir, pueden adquirir un token de forma silenciosa).

Por otro lado, el usuario no dio su consentimiento a Mail.Read durante la fase de autenticación; por lo tanto, se le pedirá su consentimiento al solicitar un token de acceso para el ámbito Mail.Read. El token recibido contendrá todos los alcances para los que ya se había otorgado consentimiento (para ese recurso específico), de ahí el término consentimiento incremental.

Considere un caso ligeramente diferente:

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

En el fragmento de código anterior, aunque el usuario da su consentimiento a los ámbitos User.Read y api://<myCustomApiClientId>/My.Scope, solo recibirá un Token de acceso para MS Graph API, de acuerdo con el principio de un recurso por ámbito. Sin embargo, dado que ya han dado su consentimiento a api://<myCustomApiClientId>/My.Scope, pueden adquirir un token de acceso para ese recurso o ámbito de forma silenciosa más adelante.

En Microsoft Entra ID, el consentimiento reside más allá de la duración de la aplicación. Esto significa que, al solicitar un token de acceso para un recurso, se devolverán todos los ámbitos a los que ha dado su consentimiento previamente para ese recurso, independientemente del ámbito solicitado en el momento. En otras palabras, si hoy consiente en User.Read y Mail.Read y mañana ejecuta una nueva instancia de su aplicación solicitando un token de acceso solo para User.Read, seguirá recibiendo un token emitido para ambosUser.Read y Mail.Read. Para obtener más información, consulte Permisos y consentimiento.

  • Last updated on