Condividi tramite

Configurare l’app del Servizio app o Funzioni di Azure per l’uso delle informazioni di accesso di Microsoft Entra

  • Articolo

Nota

A partire dal 1° giugno 2024, le app appena create servizio app possono generare un nome host predefinito univoco che usa la convenzione <app-name>-<random-hash>.<region>.azurewebsites.netdi denominazione . I nomi delle app esistenti rimangono invariati. Ad esempio:

myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Per altre informazioni, vedere Nome host predefinito univoco per servizio app risorsa.

Selezionare un altro provider di autenticazione per passare a tale provider.

Questo articolo illustra come configurare l'autenticazione per il Servizio app di Azure o Funzioni di Azure in modo che l'app consenta l’accesso agli utenti con la piattaforma di identità Microsoft (Microsoft Entra) come provider di autenticazione.

Scegliere un tenant per l'applicazione e i relativi utenti

Prima che l'applicazione possa accedere agli utenti, è necessario registrarla in un tenant esterno o di forza lavoro. Se si rende disponibile l'app ai dipendenti o agli ospiti aziendali, registrare l'app in un tenant Workforce. Se l'app è destinata a utenti e clienti aziendali, registrarla in un tenant esterno.

  1. Accedere al portale di Azure e passare all’app.

  2. Nel menu a sinistra dell'app selezionare Impostazioni>Autenticazione e quindi Aggiungi provider di identità.

  3. Nella pagina Aggiungi un provider di identità selezionare Microsoft come Provider di identità per l'acceso di identità Microsoft e Microsoft Entra.

  4. In Scegliere un tenant per l'applicazione e i relativi utenti selezionare Configurazione della forza lavoro (tenant corrente) per dipendenti e guest aziendali o selezionare Configurazione esterna per consumer e clienti aziendali.

Scegliere la registrazione app

La funzionalità di autenticazione servizio app può creare automaticamente una registrazione dell'app oppure è possibile usare una registrazione creata separatamente dall'utente o da un amministratore della directory.

Creare automaticamente una nuova registrazione app, a meno che non sia necessario creare una registrazione app separatamente. È possibile personalizzare la registrazione app nell’Interfaccia di amministrazione di Microsoft Entra in un secondo momento.

Le situazioni seguenti sono i casi più comuni in cui si usa una registrazione app esistente:

  • L'account non dispone delle autorizzazioni per creare registrazioni app nel tenant di Microsoft Entra.
  • Si desidera usare una registrazione app da un tenant Microsoft Entra diverso da quello in cui si trova l'app.
  • L'opzione per creare una nuova registrazione non è disponibile per i cloud per enti pubblici.

È possibile creare e usare una nuova registrazione dell'app (opzione 1) oppure usare una registrazione esistente creata separatamente (opzione 2).

Opzione 1: Creare e usare una nuova registrazione app

Usare questa opzione, a meno che non sia necessario creare una registrazione app separatamente. È possibile personalizzare la registrazione dell'app in Microsoft Entra dopo averlo creato.

Nota

L'opzione per creare automaticamente una nuova registrazione non è disponibile per i cloud per enti pubblici. Al contrario, definire una registrazione separatamente.

  1. Selezionare Crea nuova registrazione app.

  2. Immettere il Nome per la nuova registrazione app.

  3. Selezionare il Tipo di account supportato:

    • Tenant corrente - Tenant singolo. Account solo in questa directory organizzativa. Tutti gli account utente e guest nella directory possono usare l'applicazione o l'API. Usare questa opzione se il gruppo di destinatari è interno all'organizzazione.
    • Qualunque directory di Microsoft Entra - Multitenant. Account in qualsiasi directory organizzativa. Tutti gli utenti con un account Microsoft aziendale o dell'istituto di istruzione possono usare l'applicazione o l'API. Questi account includono istituti di istruzione e aziende che usano Office 365. Usare questa opzione se il gruppo di destinatari è costituito da clienti aziendali o di istituti di istruzione e per abilitare il multi-tenancy.
    • Qualunque directory di Microsoft Entra e account di Microsoft personali. Account in qualunque directory organizzativa e account di Microsoft personali (ad esempio Skype, Xbox). Tutti gli utenti con un account aziendale o dell'istituto di istruzione o con un account Microsoft personale possono usare l'applicazione o l'API. Sono inclusi gli istituiti di istruzione e le aziende che usano Office 365, nonché gli account personali usati per accedere a servizi come Xbox e Skype. Usare questa opzione per includere il set più ampio possibile di identità Microsoft e per abilitare la multi-tenancy.
    • Solo account di Microsoft personali. Account personali usati per accedere a servizi quali Xbox e Skype. Usare questa opzione per includere il set più ampio possibile di identità Microsoft.

È possibile modificare il nome della registrazione o i tipi di account supportati in un secondo momento.

Un segreto client viene creato come impostazione dell’applicazione slot-sticky denominata MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Se si vuole gestire il segreto in Azure Key Vault, è possibile aggiornare tale impostazione in un secondo momento per usare i riferimenti a Key Vault.

Opzione 2: Usare una registrazione esistente creata separatamente

Selezionare una delle due opzioni seguenti:

  • Selezionare una registrazione dell'app esistente in questa directory e selezionare una registrazione dell'app dall'elenco a discesa.

  • Specificare i dettagli di una registrazione dell'app esistente e fornire:

    • ID applicazione (client).
    • Segreto client (scelta consigliata). Un valore segreto usato dall'applicazione per dimostrare la propria identità quando si richiede un token. Questo valore viene salvato nella configurazione dell'app come impostazione dell'applicazione slot-sticky denominata MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Se il segreto client non è impostato, le operazioni di accesso del servizio usano il flusso di concessione implicita OAuth 2.0, che non è consigliato.
    • URL autorità di certificazione, che assume il formato <authentication-endpoint>/<tenant-id>/v2.0. Sostituire <authentication-endpoint> con il valore dell’endpoint di autenticazione specifico dell'ambiente cloud. Ad esempio, un tenant Workforce in Azure globale userà "https://sts.windows.net" come endpoint di autenticazione.

Se è necessario creare manualmente una registrazione dell'app in un tenant della forza lavoro, vedere Registrare un'applicazione con Microsoft Identity Platform. Durante il processo di registrazione, prendere nota dei valori di ID applicazione (client) e segreto client.

Durante il processo di registrazione, nella sezione URI di reindirizzamento, selezionare Web per piattaforma e digitare <app-url>/.auth/login/aad/callback. Ad esempio: https://contoso.azurewebsites.net/.auth/login/aad/callback.

Dopo la creazione, modificare la registrazione app:

  1. Dal riquadro di spostamento a sinistra, selezionare Esponi un’API>Aggiungi>Salva. Questo valore identifica in modo univoco l'applicazione quando viene usata come risorsa, che consente di richiedere token che concedono l'accesso. Il valore è un prefisso per gli ambiti creati.

    Per un'app a singolo tenant è possibile usare il valore predefinito, nel formato api://<application-client-id>. È anche possibile specificare un URI più leggibile, ad esempio https://contoso.com/api, in base a uno dei domini verificati per il tenant. Per un'app multitenant è necessario fornire un URI personalizzato. Per altre informazioni sui formati accettati per gli URI ID app, vedere Procedure consigliate per la sicurezza per le proprietà dell'applicazione in Microsoft Entra ID.

  2. Seleziona Aggiungi un ambito.

    1. In Nome ambito immettere user_impersonation.
    2. In Chi può fornire il consenso, selezionare Amministratori e utenti se si desidera consentire agli utenti di fornire il consenso a questo ambito.
    3. Immettere il nome dell'ambito di consenso. Immettere una descrizione che si vuole che gli utenti visualizzino nella pagina di consenso. Immettere, ad esempio, Accesso <application-name>.
    4. Seleziona Aggiungi ambito.

  3. (Scelta consigliata) Per creare un segreto client:

    1. Dal riquadro di navigazione a sinistra, selezionare Certificati e segreti>Segreti client>Nuovo segreto client.
    2. Immettere una descrizione e una scadenza, quindi selezionare Aggiungi.
    3. Nel campo Valore, copiare il valore del segreto client. Dopo la navigazione da questa pagina, non viene visualizzata di nuovo.

  4. (Facoltativo) Per aggiungere più valori per URL di risposta, selezionare Autenticazione.

Configurare controlli aggiuntivi

Controlli aggiuntivi determinano quali richieste sono autorizzate ad accedere all'applicazione. È possibile personalizzare questo comportamento ora oppure modificare queste impostazioni in un secondo momento dalla schermata Autenticazione principale scegliendo Modifica accanto a Impostazioni autenticazione.

Per Requisito applicazione client, scegliere se:

  • Consentire richieste solo da questa applicazione
  • Consentire richieste da applicazioni client specifiche
  • Consentire richieste da qualunque applicazione (scelta sconsigliata)

Per Requisito identità, scegliere se:

  • Consentire richieste da qualunque identità
  • Consentire richieste da identità specifiche

Per Requisito tenant, scegliere se:

  • Consentire richieste solo dal tenant emittente
  • Consentire richieste da tenant specifici
  • Usare le restrizioni predefinite in base all'emittente

L'app potrebbe comunque dover prendere altre decisioni di autorizzazione nel codice. Per altre informazioni, vedere Usare criteri di autorizzazione predefiniti.

Configurare impostazioni di autenticazione

Queste opzioni determinano il modo in cui l'applicazione risponde alle richieste non autenticate. Le selezioni predefinite reindirizzano tutte le richieste di accesso con questo nuovo provider. È possibile modificare questo comportamento ora oppure modificare queste impostazioni in un secondo momento dalla schermata Autenticazione principale scegliendo Modifica accanto a Impostazioni autenticazione. Per altre informazioni, vedere Flusso di autenticazione.

Per Limita l'accesso, decidere se:

  • Richiedere l'autenticazione
  • Consentire l’accesso non autenticato

Per Richieste non autenticate

  • HTTP 302 Reindirizzamento trovato: consigliato per i siti Web
  • HTTP 401 Non autorizzato: consigliato per le API
  • HTTP 403 Non consentito
  • HTTP 404 Non trovato

Selezionare Archivio token (scelta consigliata). L'archivio token raccoglie, archivia e aggiorna i token per l'applicazione. È possibile disabilitare questo comportamento in un secondo momento se l'app non richiede token o è necessario ottimizzare le prestazioni.

Aggiungere il provider di identità

Se è stata selezionata la configurazione Workforce, è possibile selezionare Avanti: Autorizzazioni e aggiungere le autorizzazioni di Microsoft Graph necessarie per l'applicazione. Queste autorizzazioni vengono aggiunte alla registrazione dell'app, ma è anche possibile modificarle in un secondo momento. Se è stata selezionata la configurazione esterna, è possibile aggiungere le autorizzazioni di Microsoft Graph in un secondo momento.

  • Selezionare Aggiungi.

A questo punto, è possibile usare Microsoft Identity Platform per l'autenticazione nell'app. Il provider è elencato nella schermata Autenticazione . Da qui è possibile modificare o eliminare questa configurazione del provider.

Per un esempio di configurazione dell'accesso di Microsoft Entra per un'app Web che accede a Archiviazione di Azure e Microsoft Graph, vedere Aggiungere l'autenticazione dell'app all'app Web.

Autorizzare le richieste

Per impostazione predefinita, servizio app l'autenticazione gestisce solo l'autenticazione. Determina se il chiamante è chi dice di essere. L'autorizzazione, determinando se il chiamante deve avere accesso a una risorsa, è un passaggio oltre l'autenticazione. Per altre informazioni, vedere Nozioni di base sull'autorizzazione.

L'app può prendere decisioni di autorizzazione nel codice. servizio app L'autenticazione fornisce alcuni controlli predefiniti, che possono essere utili, ma potrebbero non essere sufficienti per soddisfare le esigenze di autorizzazione dell'app.

Suggerimento

Le applicazioni multi-tenant devono convalidare l'autorità di certificazione e l'ID tenant della richiesta come parte di questo processo per assicurarsi che i valori siano consentiti. Quando servizio app l'autenticazione è configurata per uno scenario multi-tenant, non convalida il tenant da cui proviene la richiesta. Potrebbe essere necessario limitare un'app a tenant specifici, in base a se l'organizzazione ha effettuato l'iscrizione al servizio, ad esempio. Vedere Aggiornare il codice per gestire più valori dell'autorità di certificazione.

Eseguire convalide dal codice dell'applicazione

Quando si eseguono controlli di autorizzazione nel codice dell'app, è possibile usare le informazioni sulle attestazioni rese disponibili dall'autenticazione del Servizio app. Per altre informazioni, vedere Accedere alle attestazioni utente nel codice dell'app.

L'intestazione x-ms-client-principal inserita contiene un oggetto JSON con codifica Base64 con le attestazioni asserite sul chiamante. Per impostazione predefinita, queste attestazioni passano attraverso un mapping delle attestazioni, quindi i nomi delle attestazioni potrebbero non corrispondere sempre a quello visualizzato nel token. Ad esempio, l'attestazione tid viene mappata a http://schemas.microsoft.com/identity/claims/tenantid.

È anche possibile usare direttamente il token di accesso sottostante dall'intestazione x-ms-token-aad-access-token inserita.

Usare criteri di autorizzazione predefiniti

La registrazione app creata autentica le richieste in ingresso per il tenant di Microsoft Entra. Per impostazione predefinita, consente anche a chiunque all'interno del tenant di accedere all'applicazione. Questo approccio è adatto a molte applicazioni. Alcune applicazioni devono limitare ulteriormente l'accesso prendendo decisioni di autorizzazione. Il codice dell'applicazione è spesso la posizione migliore per gestire la logica di autorizzazione personalizzata. Per scenari comuni, tuttavia, Microsoft Identity Platform fornisce controlli predefiniti che è possibile usare per limitare l'accesso.

Questa sezione illustra come abilitare i controlli predefiniti usando l’API di autenticazione di Servizio app V2. Attualmente, l'unico modo per configurare questi controlli predefiniti consiste nell'usare i modelli di Azure Resource Manager o l'API REST.

All'interno dell'oggetto API, la configurazione del provider di identità di Microsoft Entra include una sezione validation che può contenere un oggetto defaultAuthorizationPolicy come nella struttura seguente:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Proprietà Descrizione
defaultAuthorizationPolicy Un gruppo di requisiti che devono essere soddisfatti per accedere all'app. L'accesso viene concesso in base a un AND logico su ognuna delle proprietà configurate. Quando allowedApplications e allowedPrincipals sono entrambi configurati, la richiesta in ingresso deve soddisfare entrambi i requisiti per poter essere accettata.
allowedApplications Elenco consentito di ID client dell'applicazione stringa che rappresentano la risorsa client che chiama nell'app. Quando questa proprietà è configurata come matrice non vuoto, vengono accettati solo i token ottenuti da un'applicazione specificata nell'elenco.

Questo criterio valuta l'attestazione appid o azp del token in ingresso, che deve essere un token di accesso. Vedere Attestazioni di payload.
allowedPrincipals Un gruppo di controlli che determinano se l'entità rappresentata dalla richiesta in ingresso può accedere all'app. La soddisfazione di allowedPrincipals si basa su un OR logico per le proprietà configurate.
identities (in allowedPrincipals) Elenco consentito di ID oggetto stringa che rappresenta utenti o applicazioni a cui è consentito l'accesso. Quando questa proprietà è configurata come array non vuoto, il requisito allowedPrincipals può essere soddisfatto se l'utente o l'applicazione rappresentata dalla richiesta è specificato nell'elenco. È previsto un limite di 500 caratteri nell'elenco delle identità.

Questo criterio valuta l'attestazione oid del token in ingresso. Vedere Attestazioni di payload.

Inoltre, alcuni controlli possono essere configurati tramite un'impostazione dell'applicazione, indipendentemente dalla versione dell'API in uso. L'impostazione WEBSITE_AUTH_AAD_ALLOWED_TENANTS dell'applicazione può essere configurata con un elenco delimitato da virgole di un massimo di 10 ID tenant, aaaabbbb-0000-cccc-1111-dddd2222eeeead esempio .

Questa impostazione può richiedere che il token in ingresso proveni da uno dei tenant specificati, come specificato dall'attestazione tid . L'impostazione WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL dell'applicazione può essere configurata su true o 1 per richiedere al token in ingresso di includere un'attestazione oid . Se allowedPrincipals.identities è stata configurata, questa impostazione viene ignorata e considerata come true perché l'attestazione viene verificata in base all'elenco oid specificato di identità.

Alle richieste che non soddisfano questi controlli predefiniti viene assegnata una risposta HTTP 403 Forbidden.

Configurare app client per accedere al Servizio app

Nelle sezioni precedenti è stato registrato il Servizio app o la Funzione di Azure per l’autenticazione degli utenti. Questa sezione illustra come registrare client nativi o app daemon in Microsoft Entra. Possono richiedere l'accesso alle API esposte dal servizio app per conto di utenti o utenti stessi, ad esempio in un'architettura a più livelli. Se si vuole solo autenticare gli utenti, i passaggi descritti in questa sezione non sono necessari.

Applicazione client nativa

È possibile registrare client nativi per chiedere l'accesso alle API dell'app del Servizio app per conto di un utente registrato.

  1. Dal menu del portale selezionare Microsoft Entra ID.

  2. Nel riquadro di spostamento a sinistra selezionare Gestisci> Registrazioni app, quindi selezionare Nuova registrazione.

  3. Nella pagina Registra un'applicazione immettere un valore per Nome per la registrazione dell'app.

  4. In URI di reindirizzamento selezionare Client pubblico/nativo (mobile e desktop) e digitare l'URL <app-url>/.auth/login/aad/callback. Ad esempio: https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Selezionare Registra.

  6. Dopo la creazione della registrazione dell'app, copiare il valore di ID applicazione (client).

    Nota

    Per un'applicazione di Microsoft Store, usare invece il SID pacchetto come URI.

  7. Nel riquadro di spostamento a sinistra selezionare Gestisci>autorizzazioni API. Selezionare quindi Aggiungi un'autorizzazione>Api personali.

  8. Selezionare la registrazione creata in precedenza per l'app del servizio app. Se la registrazione dell'app non viene visualizzata, assicurarsi di aggiungere l'ambito user_impersonation nella registrazione dell'app.

  9. Selezionare user_impersonation in Autorizzazioni delegate, quindi selezionare Aggiungi autorizzazioni.

È stata configurata un'applicazione client nativa che può richiedere l'accesso all'app servizio app per conto di un utente.

Applicazione client daemon (chiamate da servizio a servizio)

In un'architettura a più livelli, l'applicazione client può acquisire un token per chiamare un servizio app o un'app per le funzioni per conto dell'app client stessa, non per conto di un utente. Questo scenario è utile per le applicazioni daemon non interattive che eseguono attività senza un utente connesso. Usa la concessione di credenziali client OAuth 2.0 standard. Per altre informazioni, vedere Microsoft Identity Platform e il flusso delle credenziali client OAuth 2.0.

  1. Dal menu portale di Azure selezionare Microsoft Entra ID.
  2. Nel riquadro di spostamento a sinistra selezionare Gestisci> Registrazioni app> Nuova registrazione.
  3. Nella pagina Registra un'applicazione immettere un valore per Nome per la registrazione dell'app.
  4. Per un'applicazione daemon, non è necessario un URI di reindirizzamento, quindi è possibile lasciare questo campo vuoto.
  5. Selezionare Registra.
  6. Dopo la creazione della registrazione dell'app, copiare il valore di ID applicazione (client).
  7. Nel riquadro di spostamento a sinistra selezionare Gestisci>certificati e segreti. Selezionare quindi Segreti>client Nuovo segreto client.
  8. Immettere una descrizione e una scadenza, quindi selezionare Aggiungi.
  9. Nel campo Valore, copiare il valore del segreto client. Dopo la navigazione da questa pagina, non viene visualizzata di nuovo.

È ora possibile richiedere un token di accesso usando l'ID client e il segreto client. Impostare il resource parametro sull'URI ID applicazione dell'app di destinazione. Il token di accesso risultante può quindi essere presentato all'app di destinazione usando l'intestazione di autorizzazione OAuth 2.0 standard. servizio app l'autenticazione convalida e usa il token come di consueto per indicare che il chiamante è autenticato. In questo caso, il chiamante è un'applicazione, non un utente.

Questo approccio consente a qualsiasi applicazione client nel tenant di Microsoft Entra di richiedere un token di accesso ed eseguire l'autenticazione all'app di destinazione. Se si vuole applicare anche l'autorizzazione per consentire solo determinate applicazioni client, è necessario eseguire una configurazione aggiuntiva.

  1. Definire un ruolo app nel manifesto della registrazione dell'app che rappresenta il servizio app o l'app per le funzioni da proteggere.

  2. Nella registrazione dell'app che rappresenta il client che deve essere autorizzato selezionare Autorizzazioni>API Aggiungi un'autorizzazione>Api personali.

  3. Selezionare la registrazione dell'app creata in precedenza. Se non viene visualizzata la registrazione dell'app, assicurarsi di aver aggiunto un ruolo app.

  4. In Autorizzazioni applicazione selezionare il ruolo app creato in precedenza. Quindi seleziona Aggiungi autorizzazioni.

  5. Selezionare Concedi consenso amministratore per autorizzare l'applicazione client a chiedere l'autorizzazione.

    Analogamente allo scenario precedente (prima dell'aggiunta di ruoli), è ora possibile richiedere un token di accesso per la stessa destinazione resourcee il token di accesso include un'attestazione roles contenente i ruoli dell'app autorizzati per l'applicazione client.

All'interno del servizio app di destinazione o del codice dell'app per le funzioni, è ora possibile verificare che i ruoli previsti siano presenti nel token. servizio app'autenticazione non esegue questa convalida. Per altre informazioni, vedere Accedere alle attestazioni utente.

È stata configurata un'applicazione client daemon che può accedere all'app servizio app usando la propria identità.

Procedure consigliate

Indipendentemente dalla configurazione usata per configurare l'autenticazione, le procedure consigliate seguenti garantiscono una maggiore sicurezza del tenant e delle applicazioni:

  • Configurare ogni app del Servizio app con una propria registrazione in Microsoft Entra.
  • Assegnare a ogni app del servizio app le autorizzazioni specifiche e il consenso.
  • Evitare la condivisione delle autorizzazioni tra ambienti. Usare registrazioni di app separate per slot di distribuzione separati. Quando si esegue il test di nuovo codice, questa procedura consente di evitare problemi che influiscono sull'app di produzione.

Migrare a Microsoft Graph

Alcune app meno recenti potrebbero essere configurate con una dipendenza da Azure AD Graph deprecato, che è pianificata per il ritiro completo. Ad esempio, il codice dell'app potrebbe chiamare Azure AD Graph per controllare l'appartenenza al gruppo come parte di un filtro di autorizzazione in una pipeline middleware. Le app devono passare a Microsoft Graph. Per altre informazioni, vedere Eseguire la migrazione delle app da Azure AD Graph a Microsoft Graph.

Durante questa migrazione, potrebbe essere necessario apportare alcune modifiche alla configurazione dell'autenticazione di servizio app. Dopo aver aggiunto le autorizzazioni di Microsoft Graph alla registrazione dell'app, è possibile:

  1. Aggiornare l'URL dell'autorità di certificazione per includere il /v2.0 suffisso, se non lo è già.

  2. Rimuovere le richieste di autorizzazioni di Azure AD Graph dalla configurazione di accesso. Le proprietà da modificare dipendono da quale versione dell'API di gestione si sta usando:

    • Se si usa l'API V1 (/authsettings), questa impostazione si trova nella additionalLoginParams matrice.
    • Se si usa l'API V2 (/authsettingsV2), questa impostazione si trova nella loginParameters matrice.

    È necessario rimuovere qualsiasi riferimento a https://graph.windows.net, ad esempio. Questa modifica include il resource parametro , che non è supportato dall'endpoint /v2.0 o gli ambiti richiesti specificamente da Azure AD Graph.

    È anche necessario aggiornare la configurazione per richiedere le nuove autorizzazioni di Microsoft Graph configurate per la registrazione dell'applicazione. In molti casi, è possibile usare l’ambito predefinito per semplificare questa configurazione. A tale scopo, aggiungere un nuovo parametro di accesso scope=openid profile email https://graph.microsoft.com/.default.

Con queste modifiche, quando servizio app l'autenticazione tenta di accedere, non richiede più le autorizzazioni per Azure AD Graph. Ottiene invece un token per Microsoft Graph. Qualsiasi uso di tale token dal codice dell'applicazione deve anche essere aggiornato, come descritto in Eseguire la migrazione delle app da Azure AD Graph a Microsoft Graph.

Passaggi successivi