Esplorare autenticazione e autorizzazione nel servizio app
Il Servizio app di Azure fornisce supporto integrato per l'autenticazione e l'autorizzazione, in modo da poter accedere agli utenti e ai dati scrivendo un codice minimo, oppure nessun codice, nell'app Web, nell'API RESTful, nel back-end per dispositivi mobili e in Funzioni di Azure.
Perché usare l'autenticazione predefinita?
L'uso delle funzionalità di autenticazione e autorizzazione del servizio app non è obbligatorio. Molti framework Web offrono funzionalità di sicurezza integrate che è possibile usare, se lo si preferisce. Se è necessaria più flessibilità di quella offerta dal servizio app, è anche possibile scrivere utilità personalizzate.
La funzionalità di autenticazione predefinita per Servizio app e Funzioni di Azure consente di risparmiare tempo e fatica fornendo l'autenticazione immediata con provider di identità federati, consentendo di concentrarsi sul resto dell'applicazione.
- Servizio app di Azure consente di integrare un'ampia gamma di funzionalità di autenticazione nell'app Web o nell'API senza implementarle manualmente.
- È integrato direttamente nella piattaforma e non richiede alcun linguaggio, SDK, competenza in materia di sicurezza o codice particolare.
- È possibile eseguire l'integrazione con più provider di accesso. Ad esempio, Microsoft Entra ID, Facebook, Google, Twitter.
Provider di identità
Il servizio app usa l'identità federata, in cui un provider di identità di terze parti gestisce le identità utente e il flusso di autenticazione. Per impostazione predefinita, sono disponibili i provider di identità seguenti:
| Provider | Endpoint di accesso | Guida alle procedure |
|---|---|---|
| Microsoft Identity Platform | /.auth/login/aad |
Accesso tramite Microsoft Identity Platform per il servizio app |
/.auth/login/facebook |
Accesso tramite Facebook per Servizio app | |
/.auth/login/google |
Accesso tramite Google per Servizio app | |
/.auth/login/twitter |
Accesso tramite Twitter per Servizio app | |
| Qualsiasi provider OpenID Connect | /.auth/login/<providerName> |
Accesso tramite OpenID Connect per Servizio app |
| GitHub | /.auth/login/github |
Accesso GitHub del servizio app |
Se si abilitano l'autenticazione e l'autorizzazione con uno di questi provider, il relativo endpoint di accesso è disponibile per l'autenticazione utente e per la convalida dei token di autenticazione da parte del provider. È possibile fornire agli utenti un numero qualsiasi di queste opzioni di accesso.
Funzionamento
Il modulo di autenticazione e autorizzazione viene eseguito nella stessa sandbox del codice dell'applicazione. Se è abilitato, ogni richiesta HTTP in ingresso passa attraverso tale modulo prima di essere gestita dal codice dell'applicazione. Questo modulo gestisce diverse operazioni per l'app:
- Autentica utenti e client con i provider di identità specificati
- Convalida, archivia e aggiorna i token OAuth emessi dai provider di identità configurati
- Gestisce la sessione autenticata
- Inserisce le informazioni relative all'identità nelle intestazioni delle richieste HTTP
Il modulo viene eseguito separatamente dal codice dell'applicazione e può essere configurato usando le impostazioni di Azure Resource Manager o un file di configurazione. Non sono necessari SDK, linguaggi di programmazione specifici o modifiche del codice dell'applicazione.
Nota
In Linux e nei contenitori il modulo di autenticazione e autorizzazione viene eseguito in un contenitore separato, isolato dal codice dell'applicazione. Poiché non viene eseguito in-process, non è possibile eseguire l'integrazione diretta con framework di linguaggio specifici.
Flusso di autenticazione
Il flusso di autenticazione è lo stesso per tutti i provider, ma varia a seconda che si voglia accedere con l'SDK del provider.
Senza provider SDK: l'applicazione delega l'accesso federato al servizio app. Questo è in genere il caso delle app del browser, che possono presentare all'utente la pagina di accesso del provider. Il codice del server gestisce il processo di accesso, quindi viene chiamato anche flusso diretto dal server o flusso del server.
Con provider SDK: l'applicazione consente agli utenti di accedere manualmente al provider e quindi invia il token di autenticazione al servizio app per la convalida. Questo è in genere il caso delle app senza browser, che non possono presentare all'utente la pagina di accesso del provider. Il codice dell'applicazione gestisce il processo di accesso, quindi viene chiamato anche flusso diretto dal client o flusso del client. Ciò si applica alle API REST, a Funzioni di Azure, ai client del browser JavaScript e alle app native per dispositivi mobili, che consentono l'accesso agli utenti usando l'SDK del provider.
La tabella seguente mostra i passaggi del flusso di autenticazione.
| Passaggio | Senza SDK del provider | Con SDK del provider |
|---|---|---|
| Accesso dell'utente | Reindirizza il client a /.auth/login/<provider>. |
Il codice client consente l'accesso utente direttamente con l'SDK del provider e riceve un token di autenticazione. Per informazioni, vedere la documentazione del provider. |
| Post-autenticazione | Il provider reindirizza il client a /.auth/login/<provider>/callback. |
Il codice client inserisce il token del provider in /.auth/login/<provider> per la convalida. |
| Apertura di una sessione autenticata | Il servizio app aggiunge il cookie autenticato alla risposta. | Il servizio app restituisce il proprio token di autenticazione al codice client. |
| Distribuzione del contenuto autenticato | Il client include il cookie di autenticazione nelle richieste successive (gestite automaticamente dal browser). | Il codice client presenta il token di autenticazione nell'intestazione X-ZUMO-AUTH (gestita automaticamente dagli SDK client per app per dispositivi mobili). |
Per i browser client, il servizio app può indirizzare automaticamente tutti gli utenti non autenticati a /.auth/login/<provider>. È anche possibile presentare agli utenti uno o più collegamenti a /.auth/login/<provider> per consentire di accedere all'app con il provider desiderato.
Comportamento dell'autorizzazione
Nel portale di Azure è possibile configurare il servizio app con molti comportamenti quando una richiesta in ingresso non viene autenticata.
Consenti richieste non autenticate: questa opzione rinvia l'autorizzazione del traffico non autenticato al codice dell'applicazione. Per le richieste autenticate, il servizio app passa anche le informazioni di autenticazione nelle intestazioni HTTP. Questa opzione offre maggiore flessibilità nella gestione delle richieste anonime. È possibile offrire diversi provider di accesso agli utenti.
Richiedi autenticazione: questa opzione rifiuta tutto il traffico non autenticato verso l'applicazione. Questo rifiuto può essere un'azione di reindirizzamento a uno dei provider di identità configurati. In questi casi, un client browser viene reindirizzato a
/.auth/login/<provider>per il provider scelto. Se la richiesta anonima proviene da un'app per dispositivi mobili nativa, verrà restituita la rispostaHTTP 401 Unauthorized. È anche possibile configurare il rifiuto comeHTTP 401 UnauthorizedoHTTP 403 Forbiddenper tutte le richieste.Attenzione
La limitazione dell'accesso in questo modo si applica a tutte le chiamate all'app, il che potrebbe non essere opportuno per le app che desiderano una home page disponibile pubblicamente, come nel caso di molte applicazioni a pagina singola.
Archivio token
Il servizio app offre un archivio di token predefinito, ovvero un repository di token associati agli utenti delle app Web, delle API o delle app native per dispositivi mobili. Quando si abilita l'autenticazione con qualsiasi provider, questo archivio di token diventa immediatamente disponibile per l'app.
Registrazione e traccia
Se si abilita la registrazione delle applicazioni, le tracce di autenticazione e autorizzazione vengono raccolte direttamente nei file di log. Se viene visualizzato un errore di autenticazione non previsto, è possibile trovarne facilmente tutti i dettagli esaminando i log dell'applicazione esistenti.