Tracciare un flusso di accesso di un'app Web Java

Questa guida dettagliata ripercorre una richiesta di accesso attraverso codice servlet Java esemplificativo. Viene illustrato come interagiscono i browser, i Microsoft Entra ID, MSAL4J e gli helper di sessione dell'applicazione.

Identificare gli helper definiti dall'applicazione

MSAL4J fornisce le API di acquisizione di token. L'applicazione fornisce il codice circostante che coordina i reindirizzamenti del browser, l'elaborazione del callback e le sessioni. I frammenti usano questi helper illustrativi:

Questi nomi e i relativi metodi helper sono api definite dall'applicazione, non MSAL4J. I ruoli sono illustrati nella procedura dettagliata, ma le relative implementazioni non sono incluse.

Un URL di autorizzazione avvia l'interazione del browser

Il primo frammento mostra come l'applicazione crea un URL di autorizzazione e reindirizza il browser. L'helper fornisce un client riservato configurato. L'applicazione ha anche generato valori nuovi, imprevedibili state e nonce per questa richiesta di accesso e conservati per un confronto successivo.

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 descrive l'URI di callback, l'ambito richiesto e le opzioni del protocollo. Collections.singleton è appropriato in questo caso perché Config.SCOPES contiene un solo scope, anziché un elenco di più scope separati da spazi. MSAL aggiunge per impostazione predefinita gli ambiti standard di OpenID Connect openid, profile e offline_access.

Con MSAL4J 1.9.1, ResponseMode.QUERY inserisce i parametri di risposta di autorizzazione nella stringa di query del callback. Prompt.SELECT_ACCOUNT richiede la selezione dell'account. state consente di correlare la risposta alla richiesta di accesso, mentre nonce associa il token ID a tale richiesta.

getAuthorizationRequestUrl costruisce l'URL; redirectUser è l'helper definito dall'applicazione che reindirizza il browser. Nessuna delle due operazioni riscatta un codice di autorizzazione.

Il callback scambia un codice per i token

Dopo una risposta di autorizzazione riuscita, Microsoft Entra ID reindirizza il browser all'URI di callback dell'applicazione con un codice di autorizzazione. Il frammento seguente è incentrato sul riscatto, dopo che il callback ha convalidato state, ha gestito le risposte di errore ed estratto authCode. Non mostra l'intera implementazione 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 connette il codice ricevuto all'URI di callback e all'ambito richiesto. L'URI di reindirizzamento deve corrispondere a quello usato nella richiesta di autorizzazione e nella registrazione dell'app. Il client riservato autentica l'applicazione durante lo scambio del codice nell'endpoint del token.

acquireToken restituisce un futuro e .get() attende il risultato in questo esempio. Un riscatto effettuato con successo produce un oggetto IAuthenticationResult; uno scambio non riuscito deve essere gestito come un errore. I codici di autorizzazione sono di breve durata e monouso, non riutilizzabili per le chiamate API successive.

L'applicazione associa il risultato a una sessione

Il frammento successivo illustra il limite tra la ricezione di token e la gestione di una sessione come autenticata. Qui, context è un'istanza IdentityContextData definita dall'applicazione.

context.setIdTokenClaims(result.idToken());
validateNonce(context);
context.setAuthResult(result, client.tokenCache().serialize());

La prima chiamata rende disponibili i claim dell'ID token ai fini della convalida del nonce dell'applicazione. La funzione helper definita dall'applicazione validateNonce confronta il nonce restituito con il valore memorizzato per la richiesta originale e interrompe l'elaborazione se la validazione non riesce. La chiamata finale registra il risultato dell'autenticazione e la cache dei token serializzati nel contesto dell'applicazione, che il codice circostante associa alla sessione.

Questi helper non sostituiscono le responsabilità di sicurezza più ampie dell'applicazione. Un'implementazione completa richiede anche l'elaborazione corretta delle risposte, l'archiviazione sicura della sessione e della cache dei token, la gestione degli errori appropriata e l'autorizzazione per le operazioni protette.

Connetti il flusso

Il browser porta l'utente tramite l'accesso e restituisce un codice di autorizzazione. Il server riscatta il codice con MSAL4J, elabora il risultato e gestisce la sessione dell'applicazione. Le chiamate successive a Microsoft Graph usano un token di accesso, non il codice di autorizzazione o il token ID.

Per altre informazioni sulle API della libreria, vedere Generatore URL del codice di autorizzazione MSAL4J e Acquisire token con codici di autorizzazione.