Descripción de la autorización de API y el almacenamiento en caché de tokens
El diseño del portal de empresa incluye leer el perfil del usuario que ha iniciado sesión desde Microsoft Graph. La autenticación identifica al usuario en el portal, pero una llamada API también necesita un token de acceso con los permisos adecuados.
En esta unidad se explican los tipos de permisos, los ámbitos y un patrón ilustrativo de caché de tokens de MSAL4J. No presupone que haya una aplicación en ejecución o una sesión iniciada.
Permisos y ámbitos de API
Una API protegida define los permisos para su funcionalidad y sus datos. Microsoft Graph, por ejemplo, tiene permisos diferentes para leer un perfil, leer un calendario y enviar correo. Una aplicación solicita solo los permisos necesarios para su operación prevista.
Microsoft Entra ID admite dos tipos de permisos:
| Tipo de permiso | Context | Consentimiento |
|---|---|---|
| Permisos delegados | La aplicación actúa en nombre de un usuario que ha iniciado sesión. El acceso está condicionado por los permisos concedidos y el nivel de acceso del usuario. | Un usuario o un administrador autorizado puede otorgar su consentimiento, en función de la directiva de permisos y del inquilino. |
| Permisos de aplicación | La aplicación actúa como sí misma sin un usuario que ha iniciado sesión, como un servicio en segundo plano. | Se requiere el consentimiento del administrador. |
El portal usa permisos delegados User.Read para leer el perfil del usuario que ha iniciado sesión. Este permiso no concede acceso a los datos de cada usuario ni a recursos no relacionados, como calendarios.
Los ámbitos describen el acceso solicitado
En una solicitud de autorización delegada, los ámbitos de OAuth 2.0 expresan los permisos que solicita la aplicación. Un ámbito puede identificar tanto el recurso como el permiso; por ejemplo, https://graph.microsoft.com/Calendars.Read solicita permiso de lectura de calendario para Microsoft Graph.
En los ejemplos se usa el ámbito User.Readúnico . En los ámbitos de Microsoft Graph, se puede omitir el identificador del recurso, así que esto representa https://graph.microsoft.com/User.Read. Para obtener más información, consulte Ámbitos y permisos.
Los permisos de API configurados, los ámbitos solicitados y el consentimiento son distintos. Agregar un permiso de API a un registro de aplicación no concede consentimiento ni cambia los ámbitos solicitados por el código de la aplicación.
Un token de acceso es específico de su API
Un token de acceso está pensado para un recurso determinado. Un token para Microsoft Graph no es intercambiable con un token para otra API y un token de identificador no es un reemplazo de un token de acceso de API.
MSAL4J adquiere y almacena en caché tokens. La aplicación usa el token para su recurso previsto en lugar de analizarlo para realizar suposiciones sobre la identidad del usuario que ha iniciado sesión o tratarlo como un código de autorización reutilizable.
Ilustración de la adquisición silenciosa de tokens
Para las solicitudes posteriores, una aplicación web puede pedir a MSAL un token sin enviar al usuario a través de otra interacción de inicio de sesión. El siguiente fragmento está adaptado del AuthHelperejemplo de referencia. Ilustra la restauración de una caché asociada a la sesión y la solicitud de un token para una cuenta ya representada en ese contexto.
final SilentParameters parameters = SilentParameters
.builder(Collections.singleton(Config.SCOPES), context.getAccount())
.build();
final ConfidentialClientApplication client = getConfidentialClientInstance();
client.tokenCache().deserialize(context.getTokenCache());
final IAuthenticationResult result = client.acquireTokenSilently(parameters).get();
SilentParameters identifica el ámbito y la cuenta solicitados. En este ejemplo, Config.SCOPES contiene User.Ready context proporciona la cuenta y la caché serializada asociada a la sesión autenticada. Se trata de ejemplos de ayudantes de aplicación, no de valores que el alumno deba obtener.
Una vez restaurada la memoria caché, acquireTokenSilently intenta satisfacer la solicitud sin interacción del usuario. Puede devolver un token de acceso almacenado en caché utilizable o usar un token de actualización en caché cuando sea aplicable. "Silencioso" no significa necesariamente que no se produzca ninguna solicitud de red.
Este fragmento omite la persistencia de caché circundante y el control de excepciones. Si MSAL indica que es necesaria la interacción del usuario, la aplicación web inicia una nueva solicitud de autorización y procesa la respuesta de redirección resultante. No canjea de nuevo el código de autorización anterior. Otros errores, como errores de red o de configuración, necesitan un control de errores adecuado en lugar de un bucle de inicio de sesión incondicional.
La caché de tokens y los datos de sesión contienen información confidencial. Una aplicación completa debe proteger esos datos, asociarlos a la cuenta y la sesión correctos, y conservar los cambios de caché adecuadamente.
Interpretación del resultado antes de la llamada API
La obtención correcta del token produce un IAuthenticationResult que contiene el token de acceso e información sobre su tiempo de vida y el contexto de la cuenta. Para una solicitud de Microsoft Graph, la aplicación proporciona el token de acceso de Graph a su cliente HTTP o proveedor de autenticación de Graph.
MSAL4J no lee el perfil de un usuario simplemente mediante la adquisición de ese token. La solicitud de API independiente realiza la operación de datos.
Microsoft Graph proporciona el recurso
Microsoft Graph expone los datos y servicios en la nube de Microsoft a través de https://graph.microsoft.com. El /v1.0/me punto de conexión representa al usuario que ha iniciado sesión y requiere un contexto de usuario delegado.
La siguiente unidad examina una solicitud ilustrativa a ese punto de conexión y la solicitud equivalente a través del SDK de Java Graph. La introducción a Microsoft Graph describe la API más amplia.