Rastrea un flujo de inicio de sesión de una aplicación web Java
En este tutorial se realiza un seguimiento de una solicitud de inicio de sesión mediante código ilustrativo Java servlet. Explica cómo interactúan los asistentes de sesión del explorador, Microsoft Entra ID, MSAL4J y la aplicación.
Note
Estos fragmentos no son una aplicación completa ni una implementación lista para producción. Omiten el código de servlet circundante, las importaciones, la configuración y algún control de errores para centrarse en el flujo. No es necesario compilar ni ejecutar ninguna aplicación para completar esta unidad.
Identificación de los asistentes definidos por la aplicación
MSAL4J proporciona las API de adquisición de tokens. La aplicación proporciona el código de soporte que coordina las redirecciones del navegador, el procesamiento de retrollamadas y las sesiones. Los fragmentos usan estos asistentes ilustrativos:
| Ayudante | Rol en los ejemplos |
|---|---|
Config |
Proporciona la configuración de la aplicación.
REDIRECT_URI representa el URI de devolución de llamada registrado y SCOPES contiene el único ámbito de Microsoft Graph User.Read. |
getConfidentialClientInstance y AuthHelper.getConfidentialClientInstance |
Devuelve un objeto configurado ConfidentialClientApplication. |
contextAdapter |
Conecta la solicitud HTTP y la respuesta al contexto de sesión de la aplicación. Su redirectUser método redirige el explorador. |
IdentityContextData y context |
Contiene los datos asociados a una solicitud de inicio de sesión y una sesión, incluidas las notificaciones nonce, las notificaciones de token, el resultado de la autenticación y la caché de tokens serializada. |
Estos nombres y sus métodos auxiliares están definidos por la aplicación, no son APIs de MSAL4J. Sus roles se explican en el tutorial, pero no se incluyen sus implementaciones.
Una dirección URL de autorización inicia la interacción del explorador
El primer fragmento muestra cómo la aplicación crea una dirección URL de autorización y redirige el explorador. El asistente proporciona un cliente confidencial configurado. La aplicación también ha generado valores nuevos, imprevisibles state y nonce para esta solicitud de inicio de sesión y los ha conservado para realizar una comparación posterior.
final ConfidentialClientApplication client = getConfidentialClientInstance();
AuthorizationRequestUrlParameters parameters = AuthorizationRequestUrlParameters
.builder(Config.REDIRECT_URI, Collections.singleton(Config.SCOPES))
.responseMode(ResponseMode.QUERY)
.prompt(Prompt.SELECT_ACCOUNT)
.state(state)
.nonce(nonce)
.build();
final String authorizeUrl = client.getAuthorizationRequestUrl(parameters).toString();
contextAdapter.redirectUser(authorizeUrl);
AuthorizationRequestUrlParameters describe el URI de devolución de llamada, el ámbito solicitado y las opciones de protocolo.
Collections.singleton es adecuado aquí porque Config.SCOPES contiene un ámbito, en lugar de una lista separada por espacios de varios ámbitos. MSAL agrega de forma predeterminada los ámbitos estándar de OpenID Connect openid, profile y offline_access.
Con MSAL4J 1.9.1, ResponseMode.QUERY coloca los parámetros de respuesta de autorización en la cadena de consulta de la devolución de llamada.
Prompt.SELECT_ACCOUNT solicita la selección de la cuenta.
state ayuda a correlacionar la respuesta con la solicitud de inicio de sesión, mientras nonce enlaza el token de identificador a esa solicitud.
Note
A partir de MSAL4J 1.24.0, ResponseMode.QUERY está en desuso. Cuando se pasa este valor, AuthorizationRequestUrlParameters.Builder.responseMode sustituye ResponseMode.FORM_POST y registra una advertencia. Se trata de un cambio de comportamiento de biblioteca; Microsoft Entra todavía admite respuestas de código de autorización en modo de consulta en el nivel de protocolo.
Para las respuestas de envío de formularios, un callback de servlet requiere un manejo que admita POST, como doPost, en lugar de depender únicamente de doGet. El procesamiento de la llamada de retorno debe conservar la sesión asociada, la validación de state y nonce, y la administración de errores. Cambiar únicamente el enum del modo de respuesta no cubre estas responsabilidades.
getAuthorizationRequestUrl construye la dirección URL; redirectUser es el asistente definido por la aplicación que redirige el explorador. Ninguna operación canjea un código de autorización.
Importante
La solicitud mostrada incluye permisos delegados de Microsoft Graph User.Read durante el inicio de sesión. Una solicitud de consentimiento solo aparece cuando se necesita consentimiento y la directiva de inquilino permite al usuario concederlo; el consentimiento previo del usuario o administrador puede significar que no aparece ninguna solicitud. Un mensaje Se necesita la aprobación de un administrador indica que un administrador autorizado debe revisar la solicitud mediante el proceso aprobado por la organización. La respuesta adecuada no es debilitar la directiva de consentimiento a nivel de inquilino. Consulte Consentimiento del usuario y del administrador.
La llamada de retorno canjea un código por tokens.
Tras una respuesta de autorización satisfactoria, Microsoft Entra ID redirige el navegador al URI de devolución de llamada de la aplicación con un código de autorización. El siguiente fragmento se centra en el canje, una vez que la llamada de retorno ha validado state, administrado las respuestas de error y extraído authCode. No se muestra la implementación completa del callback.
final AuthorizationCodeParameters authParams = AuthorizationCodeParameters
.builder(authCode, new URI(Config.REDIRECT_URI))
.scopes(Collections.singleton(Config.SCOPES))
.build();
final ConfidentialClientApplication client = AuthHelper.getConfidentialClientInstance();
final IAuthenticationResult result = client.acquireToken(authParams).get();
AuthorizationCodeParameters conecta el código recibido al URI de devolución de llamada y al ámbito solicitado. El URI de redirección debe coincidir con el usado en la solicitud de autorización y el registro de la aplicación. El cliente confidencial autentica la aplicación al intercambiar el código en el punto de conexión del token.
acquireToken devuelve un futuro y .get() espera su resultado en este ejemplo. Un canje correcto genera un IAuthenticationResult; un canje fallido debe tratarse como un error. Los códigos de autorización son de corta duración y de uso único, no credenciales reutilizables para llamadas API posteriores.
Note
Para las nuevas implementaciones, siga las instrucciones de flujo de código de autorización actuales: Microsoft recomienda proof key for Code Exchange (PKCE) para todos los tipos de aplicación, incluidas las aplicaciones web confidenciales. PKCE es necesario para las aplicaciones de página única (SPA), pero no es un requisito de plataforma para la aplicación web confidencial que se muestra aquí.
Las API explícitas de MSAL4J para la construcción de URL y el canje de códigos que se muestran aquí no generan automáticamente los parámetros PKCE. Genere un verificador nuevo e imprevisible para cada solicitud de inicio de sesión y guárdelo de forma segura para el callback correspondiente. En el generador de solicitudes de autorización, proporcione su desafío derivado de S256 como codeChallenge y establezca codeChallengeMethod("S256"); en el generador de canje, proporcione la coincidencia codeVerifier. PKCE no reemplaza la autenticación del cliente ni la validación de state y nonce. Los fragmentos anteriores omiten estas entradas PKCE.
La aplicación asocia el resultado a una sesión.
En el fragmento siguiente se muestra el límite entre recibir tokens y tratar una sesión como autenticada. Aquí, context es una instancia de IdentityContextData definida por la aplicación.
context.setIdTokenClaims(result.idToken());
validateNonce(context);
context.setAuthResult(result, client.tokenCache().serialize());
La primera llamada pone las declaraciones del token de ID a disposición de la validación del nonce de la aplicación. La función auxiliar definida por la aplicación validateNonce compara el nonce devuelto con el valor conservado para la solicitud original y detiene el procesamiento si la validación falla. La llamada final registra el resultado de autenticación y la caché de tokens serializadas en el contexto de la aplicación, que el código circundante asocia a la sesión.
Estos asistentes no reemplazan las responsabilidades de seguridad más amplias de la aplicación. Una implementación completa también necesita el procesamiento de respuesta correcto, el almacenamiento seguro de sesión y caché de tokens, el control de errores adecuado y la autorización para las operaciones protegidas.
Conecta el flujo
El explorador lleva al usuario a través del inicio de sesión y devuelve un código de autorización. El servidor canjea ese código con MSAL4J, procesa el resultado y mantiene la sesión de la aplicación. Las llamadas posteriores a Microsoft Graph usan un token de acceso, no el código de autorización ni el token de identificador.
Para obtener más información sobre las API de la biblioteca, consulte Generador de direcciones URL de código de autorización de MSAL4J y Adquirir tokens con códigos de autorización.