Informazioni sul flusso di concessione implicita OAuth2 in Azure Active Directory (AD)

Avvertimento

Questo contenuto riguarda l'endpoint di Azure AD v1.0 precedente. Usare l' Microsoft Identity Platform per i nuovi progetti.

La concessione implicita OAuth2 è nota per essere la concessione con l'elenco più lungo di problemi di sicurezza nella specifica OAuth2. E ancora, questo è l'approccio implementato da ADAL JS e quello consigliato durante la scrittura di applicazioni SPA. Che c'è? È tutta una questione di compromessi: e come si scopre, la concessione implicita è l'approccio migliore che è possibile perseguire per le applicazioni che usano un'API Web tramite JavaScript da un browser.

Che cos'è la concessione implicita OAuth2?

La concessione di codice di autorizzazione quintessenziale di OAuth2 è la concessione di autorizzazione che utilizza due endpoint separati. L'endpoint di autorizzazione viene usato per la fase di interazione dell'utente, che genera un codice di autorizzazione. L'endpoint del token viene quindi usato dal client per lo scambio del codice per un token di accesso e spesso anche un token di aggiornamento. Le applicazioni Web devono presentare le proprie credenziali dell'applicazione all'endpoint del token, in modo che il server di autorizzazione possa autenticare il client.

La concessione implicita OAuth2 è una variante di altre concessioni di autorizzazione. Consente a un client di ottenere un token di accesso (e id_token, quando si usa OpenId Connect) direttamente dall'endpoint di autorizzazione, senza contattare l'endpoint del token né autenticare il client. Questa variante è stata progettata per le applicazioni basate su JavaScript in esecuzione in un Web browser: nella specifica OAuth2 originale i token vengono restituiti in un frammento di URI. In questo modo i bit del token sono disponibili per il codice JavaScript nel client, ma garantisce che non verranno inclusi nei reindirizzamenti verso il server. Nella concessione implicita OAuth2, l'endpoint di autorizzazione rilascia i token di accesso direttamente al client usando un URI di reindirizzamento fornito in precedenza. Ha anche il vantaggio di eliminare i requisiti per le chiamate cross-origin, che sono necessarie se l'applicazione JavaScript deve contattare l'endpoint del token.

Una caratteristica importante della concessione implicita OAuth2 è il fatto che tali flussi non restituiscono mai token di aggiornamento al client. La sezione successiva illustra come questo non è necessario e sarebbe in effetti un problema di sicurezza.

Scenari adatti alla concessione implicita OAuth2

La specifica OAuth2 dichiara che la concessione implicita è stata concepita per abilitare le applicazioni agente utente, vale a dire applicazioni JavaScript in esecuzione in un browser. La caratteristica di definizione di tali applicazioni è che il codice JavaScript viene usato per accedere alle risorse server (in genere un'API Web) e per aggiornare di conseguenza l'esperienza utente dell'applicazione. Si pensi ad applicazioni come Gmail o Outlook Web Access: quando si seleziona un messaggio dalla posta in arrivo, solo il pannello di visualizzazione dei messaggi cambia per visualizzare la nuova selezione, mentre il resto della pagina rimane invariato. Questa caratteristica è in contrasto con le tradizionali app Web basate sul reindirizzamento, in cui ogni interazione dell'utente comporta un postback di pagina completa e un rendering a pagina completa della nuova risposta del server.

Le applicazioni che tengono l'approccio basato su JavaScript all'estremo sono chiamate applicazioni a pagina singola o app a pagina singola. L'idea è che queste applicazioni servono solo una pagina HTML iniziale e javaScript associata, con tutte le interazioni successive guidate dalle chiamate API Web eseguite tramite JavaScript. Tuttavia, gli approcci ibridi, in cui l'applicazione è principalmente guidata dal postback, ma esegue chiamate JS occasionali, non sono insoliti. La discussione sull'utilizzo implicito del flusso è rilevante anche per quelli.

Le applicazioni basate sul reindirizzamento proteggono in genere le richieste tramite cookie, ma questo approccio non funziona anche per le applicazioni JavaScript. I cookie funzionano solo sul dominio per cui sono stati generati, mentre le chiamate JavaScript potrebbero essere indirizzate ad altri domini. In effetti, questo avvierà spesso: si pensi alle applicazioni che richiamano l'API Microsoft Graph, l'API di Office, l'API di Azure, tutti residenti all'esterno del dominio da cui viene servita l'applicazione. Una tendenza crescente per le applicazioni JavaScript è quella di non avere alcun back-end, basandosi su 100% su API Web di terze parti per implementare la propria funzione aziendale.

Attualmente, il metodo preferito per proteggere le chiamate a un'API Web consiste nell'usare l'approccio del token di connessione OAuth2, in cui ogni chiamata è accompagnata da un token di accesso OAuth2. L'API Web esamina il token di accesso in ingresso e, se lo trova negli ambiti necessari, concede l'accesso all'operazione richiesta. Il flusso implicito offre un meccanismo pratico per le applicazioni JavaScript per ottenere i token di accesso per un'API Web, offrendo numerosi vantaggi per quanto riguarda i cookie:

• I token possono essere ottenuti in modo affidabile senza alcuna necessità di chiamate tra le origini: registrazione obbligatoria dell'URI di reindirizzamento a cui i token restituiscono garanzie che i token non vengono spostati
• Le applicazioni JavaScript possono ottenere il maggior numero di token di accesso necessari per tutte le API Web di destinazione, senza restrizioni sui domini
• Funzionalità HTML5 come sessione o archiviazione locale concedono il controllo completo sulla memorizzazione nella cache dei token e sulla gestione della durata, mentre la gestione dei cookie è opaca per l'app
• I token di accesso non sono soggetti ad attacchi di falsificazione di richiesta intersito (CSRF)

Il flusso di concessione implicita non rilascia token di aggiornamento, principalmente per motivi di sicurezza. Un token di aggiornamento non è limitato come token di accesso, concedendo molto più potenza, infliggendo così molto più danni in caso di perdita. Nel flusso implicito, i token vengono recapitati nell'URL, quindi il rischio di intercettazione è superiore a quello della concessione del codice di autorizzazione.

Tuttavia, un'applicazione JavaScript dispone di un altro meccanismo a sua disposizione per rinnovare i token di accesso senza richiedere ripetutamente all'utente le credenziali. L'applicazione può usare un iframe nascosto per eseguire nuove richieste di token sull'endpoint di autorizzazione di Azure AD: purché il browser disponga ancora di una sessione attiva (lettura: ha un cookie di sessione) sul dominio di Azure AD, la richiesta di autenticazione può verificarsi correttamente senza alcuna necessità di interazione dell'utente.

Questo modello concede all'applicazione JavaScript la possibilità di rinnovare in modo indipendente i token di accesso e persino acquisire nuovi token per una nuova API (purché l'utente abbia precedentemente acconsentito per loro). In questo modo si evita il carico aggiuntivo di acquisizione, gestione e protezione di un artefatto di valore elevato, ad esempio un token di aggiornamento. L'artefatto che rende possibile il rinnovo invisibile all'utente, il cookie di sessione di Azure AD, viene gestito all'esterno dell'applicazione. Un altro vantaggio di questo approccio è che un utente può disconnettersi da Azure AD utilizzando una qualsiasi delle applicazioni che hanno eseguito l'accesso ad Azure AD, aperta in una delle schede del browser. Ciò comporta l'eliminazione del cookie di sessione di Azure AD e l'applicazione JavaScript perderà automaticamente la possibilità di rinnovare i token per l'utente disconnesso.

La concessione implicita è adatta per l'app?

La concessione implicita presenta più rischi rispetto ad altre concessioni e le aree a cui è necessario prestare attenzione sono ben documentate (ad esempio, Uso improprio del token di accesso per rappresentare il proprietario delle risorse nel flusso implicito e Considerazioni sul modello di minaccia e sul modello di minaccia OAuth 2.0). Tuttavia, il profilo di rischio più elevato è in gran parte dovuto al fatto che è destinato ad abilitare le applicazioni che eseguono codice attivo, gestite da una risorsa remota a un browser. Se si pianifica un'architettura a pagina singola, non sono presenti componenti back-end o si intende richiamare un'API Web tramite JavaScript, è consigliabile usare il flusso implicito per l'acquisizione di token.

Se l'applicazione è un client nativo, il flusso implicito non è ideale. L'assenza del cookie di sessione di Azure AD nel contesto di un client nativo impedisce all'applicazione di mantenere una sessione di lunga durata. Ciò significa che l'applicazione richiederà ripetutamente all'utente di ottenere i token di accesso per le nuove risorse.

Se si sviluppa un'applicazione Web che include un back-end e si usa un'API dal codice back-end, il flusso implicito non è adatto. Altre concessioni ti danno molto più potere. Ad esempio, la concessione di credenziali client OAuth2 consente di ottenere token che riflettono le autorizzazioni assegnate all'applicazione stessa, anziché le deleghe utente. Ciò significa che il client ha la possibilità di mantenere l'accesso a livello di codice alle risorse anche quando un utente non è attivamente impegnato in una sessione e così via. Non solo questo, ma tali concessioni offrono garanzie di sicurezza più elevate. Ad esempio, i token di accesso non transitano mai attraverso il browser utente, non rischiano di essere salvati nella cronologia del browser e così via. L'applicazione client può anche eseguire l'autenticazione avanzata quando si richiede un token.

Passaggi successivi

• Per altre informazioni sul processo di integrazione dell'applicazione, vedere Come integrare un'applicazione con Azure AD .