Autenticazione e autorizzazione nel Servizio app di Azure e Funzioni di Azure

2025-04-22

Servizio app di Azure fornisce funzionalità di autenticazione predefinite (accesso utenti) e autorizzazione (che forniscono l'accesso ai dati sicuri). Queste funzionalità sono talvolta denominate Easy Auth. È possibile usarli per accedere agli utenti e accedere ai dati scrivendo poco o nessun codice nell'app Web, nell'API RESTful, nel server mobile e nelle funzioni.

Questo articolo descrive in che modo il servizio app aiuta a semplificare l'autenticazione e l'autorizzazione per l'app.

Motivi per usare l'autenticazione predefinita

Per implementare l'autenticazione e l'autorizzazione, è possibile usare le funzionalità di sicurezza in bundle nel framework Web preferito oppure scrivere strumenti personalizzati. L'implementazione di una soluzione sicura per l'autenticazione e l'autorizzazione può richiedere notevoli sforzi. È necessario seguire le procedure consigliate e gli standard del settore. È anche necessario assicurarsi che la soluzione rimanga aggiornata con gli aggiornamenti più recenti di sicurezza, protocollo e browser.

Le funzionalità predefinite di Servizio app e Funzioni di Azure consentono di risparmiare tempo e impegno fornendo l'autenticazione predefinita con provider di identità federati, in modo da potersi concentrare sul resto dell'applicazione.

Con il servizio app è possibile integrare le funzionalità di autenticazione nell'app Web o nell'API senza implementarle manualmente. Questa funzionalità è integrata direttamente nella piattaforma e non richiede un linguaggio, un SDK, un'esperienza di sicurezza o codice specifici. È possibile integrarlo con più provider di accesso, ad esempio Microsoft Entra, Facebook, Google e X.

L'app potrebbe dover supportare scenari più complessi, ad esempio l'integrazione di Visual Studio o il consenso incrementale. Sono disponibili diverse soluzioni di autenticazione per supportare questi scenari. Per altre informazioni, vedere Scenari di autenticazione e raccomandazioni.

Fornitori di identità

Il servizio app usa l'identità federata. Un provider di identità, sia Microsoft che non Microsoft, gestisce per te le identità utente e il flusso di autenticazione. Per impostazione predefinita, sono disponibili i provider di identità seguenti:

Fornitore	Endpoint di accesso	Guida alle procedure
Microsoft Entra	`/.auth/login/aad`	Accesso alla piattaforma Microsoft Entra di App Service
Facebook	`/.auth/login/facebook`	Accesso con Facebook per il servizio App
Google	`/.auth/login/google`	Accesso google al servizio app
X	`/.auth/login/x`	Accesso al servizio app X
GitHub	`/.auth/login/github`	Accesso a GitHub di App Service
Mela	`/.auth/login/apple`	Accesso al Servizio App tramite il sign-in di Apple (anteprima)
Qualsiasi provider di OpenID Connect	`/.auth/login/<providerName>`	Accesso con OpenID Connect al servizio app

Quando si configura questa funzionalità con uno di questi provider, il relativo endpoint di accesso è disponibile per l'autenticazione utente e per la convalida dei token di autenticazione del provider. È possibile fornire agli utenti un numero qualsiasi di queste opzioni di accesso.

Considerazioni sull'uso dell'autenticazione predefinita

L'abilitazione dell'autenticazione predefinita fa sì che tutte le richieste all'applicazione vengano reindirizzate automaticamente a HTTPS, indipendentemente dall'impostazione di configurazione del servizio app per applicare HTTPS. È possibile disabilitare questo reindirizzamento automatico usando l'impostazione requireHttps nella configurazione V2. È tuttavia consigliabile continuare a usare HTTPS e assicurarsi che non vengano mai trasmessi token di sicurezza su connessioni HTTP non sicure.

È possibile usare il servizio app per l'autenticazione con o senza limitare l'accesso al contenuto e alle API del sito. Impostare le restrizioni di accesso nella sezione Impostazioni>Autenticazione>Impostazioni di autenticazione dell'app Web:

Per limitare l'accesso alle app solo agli utenti autenticati, impostare Azione da eseguire quando la richiesta non è autenticata per accedere con uno dei provider di identità configurati.
Per autenticare ma non limitare l'accesso, impostare Azione da eseguire quando la richiesta non è autenticata su Consenti richieste anonime (nessuna azione).

Importante

È consigliabile dare a ciascuna registrazione dell'app la propria autorizzazione e il proprio consenso. Evitare la condivisione delle autorizzazioni tra ambienti usando registrazioni di app separate per slot di distribuzione distinti. Quando si testa un nuovo codice, questa procedura può aiutare a evitare problemi che influiscono sull'app di produzione.

Funzionamento

Architettura delle funzionalità

Il componente middleware di autenticazione e autorizzazione è una funzionalità della piattaforma in esecuzione nella stessa macchina virtuale dell'applicazione. Quando viene abilitata, ogni richiesta HTTP in ingresso passa attraverso tale componente prima che venga gestita dall'applicazione.

Il middleware della piattaforma gestisce diversi aspetti per l'app:

Autentica utenti e clienti con gli identity provider specificati
Convalida, archivia e aggiorna i token OAuth rilasciati 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. È possibile configurarla 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.

Architettura delle funzionalità in Windows (distribuzione non contenitore)

Il modulo di autenticazione e autorizzazione viene eseguito come modulo IIS nativo nello stesso ambiente sandbox dell'applicazione. Quando viene abilitata, ogni richiesta HTTP in ingresso passa attraverso di essa prima che venga gestita dall'applicazione.

Architettura delle funzionalità in Linux e contenitori

Il modulo di autenticazione e autorizzazione viene eseguito in un contenitore separato isolato dal codice dell'applicazione. Il modulo usa il modello Ambassador per interagire con il traffico in ingresso per eseguire funzionalità simili a quella di Windows. Poiché non viene eseguito in fase di elaborazione, non è possibile eseguire l'integrazione diretta con framework di linguaggio specifici. Tuttavia, le informazioni pertinenti necessarie per l'app vengono passate nelle intestazioni della richiesta.

Flusso di autenticazione

Il flusso di autenticazione è lo stesso per tutti i provider. È diverso a seconda che si voglia accedere con l'SDK del provider:

Senza l'SDK del provider: l'applicazione delega l'accesso federato al servizio app. Questa delega è in genere il caso delle app del browser, che possono presentare la pagina di accesso del provider all'utente. Il codice del server gestisce il processo di accesso, quindi viene chiamato anche flusso diretto dal server o flusso del server.

Questo caso si applica alle app browser e alle app per dispositivi mobili che usano un browser incorporato per l'autenticazione.
Con l'SDK del provider: l'applicazione effettua l'accesso degli utenti al provider manualmente. Invia quindi il token di autenticazione al servizio app per la convalida. Questo processo è in genere il caso delle app senza browser, che non possono presentare la pagina di accesso del provider all'utente. Il codice dell'applicazione gestisce il processo di accesso, quindi viene chiamato anche flusso diretto dal client o flusso client.

Questo caso si applica alle API REST, alle funzioni di Azure e ai client browser JavaScript, oltre alle app del browser che richiedono maggiore flessibilità nel processo di accesso. Si applica anche alle app per dispositivi mobili native che consentono agli utenti di accedere usando l'SDK del provider.

Le chiamate da un'app browser attendibile nel servizio app a un'altra API REST nel servizio app o funzioni di Azure possono essere autenticate tramite il flusso diretto al server. Per altre informazioni, vedere Personalizzare l'accesso e la disconnessione nell'autenticazione del Servizio app di Azure.

La tabella seguente mostra i passaggi del flusso di autenticazione.

Passaggio	Senza SDK del provider	Con SDK del provider
1. Connettere l'utente	Il provider reindirizza il client a `/.auth/login/<provider>`.	Il codice client autentica direttamente l'utente con l'SDK del provider e riceve un token di autenticazione. Per altre informazioni, vedere la documentazione del provider.
2. Eseguire la post-autenticazione	Il provider reindirizza il client a `/.auth/login/<provider>/callback`.	Il codice client invia il token dal provider a per `/.auth/login/<provider>` la convalida.
3. Stabilire una sessione autenticata	Il servizio app aggiunge un cookie autenticato alla risposta.	Il servizio app restituisce il proprio token di autenticazione al codice client.
4. Fornire contenuto autenticato	Il client include un cookie di autenticazione nelle richieste successive (gestite automaticamente dal browser).	Il codice client presenta il token di autenticazione nell'intestazione `X-ZUMO-AUTH` .

Per i browser client, il servizio app può indirizzare automaticamente tutti gli utenti non autenticati a /.auth/login/<provider>. Puoi anche presentare agli utenti uno o più /.auth/login/<provider> collegamenti per accedere all'app usando il provider preferito.

Comportamento dell'autorizzazione

Nel portale di Azure è possibile configurare il servizio app con diversi comportamenti quando una richiesta in ingresso non viene autenticata. Le sezioni seguenti descrivono le opzioni.

Importante

Per impostazione predefinita, questa funzionalità fornisce solo l'autenticazione, non l'autorizzazione. L'applicazione potrebbe comunque dover prendere decisioni di autorizzazione, oltre a eventuali controlli configurati qui.

Accesso con restrizioni

Consenti richieste non autenticate: questa opzione rinvia l'autorizzazione del traffico non autenticato al codice dell'applicazione. Per le richieste autenticate, il Servizio App include anche le informazioni di autenticazione nelle intestazioni HTTP.

Questa opzione offre maggiore flessibilità nella gestione delle richieste anonime. Ad esempio consente di presentare più opzioni di accesso agli utenti. Tuttavia richiede di scrivere codice.
Richiedi autenticazione: questa opzione rifiuta tutto il traffico non autenticato verso l'applicazione. L'azione specifica da eseguire viene specificata nella sezione Richieste non autenticate più avanti in questo articolo.

Con questa opzione non è necessario scrivere codice di autenticazione nell'app. È possibile gestire l'autorizzazione più precisa, ad esempio l'autorizzazione specifica del ruolo, esaminando le attestazioni dell'utente.

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. Se sono necessarie eccezioni, è necessario configurare i percorsi esclusi in un file di configurazione.

Nota

Quando si usa il provider di identità Microsoft per gli utenti dell'organizzazione, il comportamento predefinito è che qualsiasi utente nel tenant di Microsoft Entra può richiedere un token per l'applicazione. È possibile configurare l'applicazione in Microsoft Entra se si desidera limitare l'accesso all'app a un set definito di utenti. Il servizio app offre anche alcuni controlli di autorizzazione predefiniti di base che possono essere utili per alcune convalide. Per altre informazioni sull'autorizzazione in Microsoft Entra, vedere Dati principali sull'autorizzazione di Microsoft Entra.

Quando si usa il provider di identità Microsoft per gli utenti dell'organizzazione, il comportamento predefinito è che qualsiasi utente nel tenant di Microsoft Entra può richiedere un token per l'applicazione. È possibile configurare l'applicazione in Microsoft Entra se si desidera limitare l'accesso all'app a un set definito di utenti. Il servizio app offre anche alcuni controlli di autorizzazione predefiniti di base che possono essere utili per alcune convalide. Per altre informazioni sull'autorizzazione in Microsoft Entra, vedere Dati principali sull'autorizzazione di Microsoft Entra.

Richieste non autenticate

Reindirizzamento trovato HTTP 302: consigliato per i siti Web: reindirizza l'azione a uno dei provider di identità configurati. In questi casi, un client del browser viene reindirizzato a /.auth/login/<provider> per il provider scelto.
HTTP 401 Non autorizzato: consigliato per le API: restituisce una HTTP 401 Unauthorized risposta se la richiesta anonima proviene da un'app per dispositivi mobili nativa. È anche possibile configurare il rifiuto per essere HTTP 401 Unauthorized per tutte le richieste.
HTTP 403 Accesso negato: configura il rifiuto HTTP 403 Forbidden per tutte le richieste.
HTTP 404 Non trovato: configura il rifiuto HTTP 404 Not found per tutte le richieste.

Archivio di token

Il servizio app fornisce un archivio token predefinito. Un archivio token è 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.

Se il codice dell'applicazione deve accedere ai dati di questi provider per conto dell'utente, in genere è necessario scrivere codice per raccogliere, archiviare e aggiornare questi token nell'applicazione. Le azioni possono includere:

Pubblica sulla bacheca Facebook dell'utente autenticato.
Leggere i dati aziendali dell'utente usando l'API Microsoft Graph.

Con l'archivio di token, è sufficiente recuperare i token quando sono necessari e fare in modo che il servizio app li aggiorni quando non sono più validi.

I token ID, i token di accesso e i token di aggiornamento vengono memorizzati nella cache per la sessione autenticata. Solo l'utente associato può accedervi.

Se non è necessario usare i token nell'app, è possibile disabilitare l'archivio token nella pagina Impostazioni>Autenticazione dell'app.

Registrazione e traccia

Se si abilita la registrazione delle applicazioni, le tracce di autenticazione e autorizzazione vengono visualizzate 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.

Se si abilita la traccia delle richieste non riuscite, è possibile visualizzare esattamente il ruolo che potrebbe avere il modulo di autenticazione e autorizzazione in una richiesta non riuscita. Nei log di traccia cercare i riferimenti a un modulo denominato EasyAuthModule_32/64.

Mitigazione della richiesta intersito falso

L'autenticazione del servizio app riduce la richiesta intersito falsa controllando le richieste client per le condizioni seguenti:

Si tratta di una POST richiesta autenticata tramite un cookie di sessione.
La richiesta proviene da un browser noto, come determinato dall'intestazione HTTP User-Agent .
L'intestazione HTTP Origin o HTTP Referer è mancante o non è presente nell'elenco configurato di domini esterni approvati per il reindirizzamento.
L'intestazione HTTP Origin è mancante o non è presente nell'elenco configurato di origini CORS (Cross-Origin Resource Sharing).

Quando una richiesta soddisfa tutte queste condizioni, l'autenticazione del servizio App la rifiuta automaticamente. È possibile aggirare questa logica di mitigazione aggiungendo il dominio esterno all'elenco di reindirizzamento in Impostazioni>>Modifica impostazioni> di autenticazioneImpostazioni Url di reindirizzamento esterni consentiti.

Considerazioni sull'uso di Frontdoor di Azure

Quando si usa il servizio app di Azure con l'autenticazione dietro Frontdoor di Azure o altri proxy inversi, prendere in considerazione le azioni seguenti.

Disabilitare la memorizzazione nella cache di Frontdoor di Azure

Disabilitare la memorizzazione nella cache di Azure Front Door per il flusso di lavoro di autenticazione.

Usare l'endpoint frontdoor di Azure per i reindirizzamenti

Il servizio app in genere non è accessibile direttamente quando viene esposto da Frontdoor di Azure. È possibile evitare questo comportamento, ad esempio esponendo il servizio app usando collegamento privato di Azure in Frontdoor Premium di Azure. Per impedire al flusso di lavoro di autenticazione di reindirizzare direttamente il traffico al servizio App Service. Per altre informazioni, vedere URI di reindirizzamento.

Assicurarsi che il Servizio app di Azure usi l'URI di reindirizzamento corretto

In alcune configurazioni, il servizio app usa il nome di dominio completo (FQDN) come URI di reindirizzamento, anziché l'FQDN frontdoor di Azure. Questa configurazione causa un problema quando il client viene reindirizzato al servizio app invece di Frontdoor di Azure. Per modificarlo, impostare forwardProxy su Standard per fare in modo che App Service rispetti l'intestazione X-Forwarded-Host impostata da Azure Front Door.

Altri proxy inversi, come il gateway delle applicazioni di Azure o i prodotti non Microsoft, possono usare intestazioni diverse e richiedere un'impostazione diversa per il forwardProxy.

Non è possibile modificare la forwardProxy configurazione usando il portale di Azure. È necessario usare az rest.

Impostazioni di esportazione

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

Aggiorna impostazioni

Cercare:

"httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}

Assicurarsi che convention sia impostato su Standard per rispettare l'intestazione X-Forwarded-Host usata da Frontdoor di Azure.

Importa impostazioni

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

Per altre informazioni sull'autenticazione del servizio app, vedere:

Per qualche esempio vedere:

Guida rapida: Aggiungere l'autenticazione delle app all'app Web in esecuzione nel Servizio App di Azure
Esercitazione: Autenticare e autorizzare gli utenti end-to-end in Azure App Service
Integrazione di .NET Core di Azure AppService Easy Auth (contenuto GitHub non Microsoft)
Recupero dell'autenticazione del servizio app di Azure con .NET Core (contenuto GitHub non Microsoft)

Condividi tramite