Configurare l'app servizio app o Funzioni di Azure per l'uso dell'accesso a Microsoft Entra

  • Articolo

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

Questo articolo illustra come configurare l'autenticazione per app Azure Service o Funzioni di Azure in modo che l'app accinga gli utenti con Microsoft Identity Platform (Microsoft Entra ID) come provider di autenticazione.

La funzionalità di autenticazione servizio app può creare automaticamente una registrazione dell'app con Microsoft Identity Platform. È anche possibile usare una registrazione creata separatamente dall'utente o da un amministratore della directory.

Nota

L'opzione per creare automaticamente una nuova registrazione non è disponibile per i cloud per enti pubblici o quando si usa [MICROSOFT Entra ID per i clienti (anteprima)]. Definire invece una registrazione separatamente.

Opzione 1: Creare automaticamente una nuova registrazione dell'app

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

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

  2. Selezionare Autenticazione nel menu a sinistra. Selezionare Aggiungi provider di identità.

  3. Selezionare Microsoft nell'elenco a discesa Provider di identità. L'opzione per creare una nuova registrazione è selezionata per impostazione predefinita. È possibile modificare il nome della registrazione o i tipi di account supportati.

    Verrà creato e archiviato un segreto client come impostazione dell'applicazione slot-sticky denominata MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. È possibile aggiornare questa impostazione in un secondo momento per usare i riferimenti a Key Vault se si vuole gestire il segreto in Azure Key Vault.

  4. Se si tratta del primo provider di identità configurato per l'applicazione, verrà visualizzata anche una sezione servizio app impostazioni di autenticazione. In caso contrario, è possibile passare al passaggio successivo.

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

  5. (Facoltativo) Selezionare Avanti: Autorizzazioni e aggiungere le autorizzazioni di Microsoft Graph necessarie per l'applicazione. Questi verranno aggiunti alla registrazione dell'app, ma è anche possibile modificarli in un secondo momento.

  6. Selezionare Aggiungi.

È ora possibile usare Microsoft Identity Platform per l'autenticazione nell'app. Il provider verrà elencato nella schermata Autenticazione . Da qui è possibile modificare o eliminare questa configurazione del provider.

Per un esempio di configurazione dell'accesso a Microsoft Entra per un'app Web che accede a Archiviazione di Azure e Microsoft Graph, vedere questa esercitazione.

Opzione 2: Usare una registrazione esistente creata separatamente

È possibile configurare servizio app'autenticazione per l'uso di una registrazione dell'app esistente. Le situazioni seguenti sono i casi più comuni per usare una registrazione dell'app esistente:

  • L'account non dispone delle autorizzazioni per creare registrazioni di app nel tenant di Microsoft Entra.
  • Si vuole usare una registrazione dell'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.

Passaggio 1: Creare una registrazione dell'app in Microsoft Entra ID per l'app servizio app

Durante la creazione della registrazione dell'app, raccogliere le informazioni seguenti necessarie in un secondo momento quando si configura l'autenticazione nell'app servizio app:

  • ID client
  • ID tenant
  • Segreto client (facoltativo, ma consigliato)
  • URI ID applicazione

Le istruzioni per la creazione di una registrazione dell'app dipendono dall'uso di un tenant della forza lavoro o di un tenant del cliente. Usare le schede seguenti per selezionare il set corretto di istruzioni per lo scenario.

Per registrare l'app, seguire questa procedura:

  1. Accedere al portale di Azure, cercare e selezionare Servizi app e quindi selezionare la propria app. Prendere nota dell'URL dell'app. Verrà usato per configurare la registrazione dell'app Microsoft Entra.

  2. Passare al tenant nel portale:

    Dal menu del portale selezionare Microsoft Entra ID. Se il tenant in uso è diverso da quello usato per configurare l'applicazione servizio app, sarà prima necessario modificare le directory.

  3. Nella schermata "Panoramica" prendere nota dell'ID tenant e del dominio primario.

  4. Nel riquadro di spostamento a sinistra selezionare Registrazioni app> Nuova registrazione.

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

  6. In Tipi di account supportati selezionare il tipo di account che può accedere a questa applicazione.

  7. 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.

  8. Selezionare Registra.

  9. Una volta creata la registrazione dell'app, copiare i valori di ID applicazione (client) e ID della directory (tenant), che serviranno più avanti.

  10. Nel riquadro di spostamento a sinistra selezionare Autenticazione. In Concessione implicita e flussi ibridi abilitare i token ID per consentire a OpenID Connessione accessi utente da servizio app. Seleziona Salva.

  11. (Facoltativo) Nel riquadro di spostamento a sinistra selezionare Personalizzazione e proprietà. In URL pagina iniziale immettere l'URL dell'app del servizio app e selezionare Salva.

  12. Nel riquadro di spostamento a sinistra selezionare Esporre un'API>Aggiungi>salva. Questo valore identifica in modo univoco l'applicazione quando viene usata come risorsa, consentendo la richiesta di token che concedono l'accesso. Viene usato come prefisso per gli ambiti creati.

    Per un'app a tenant singolo, è possibile usare il valore predefinito, che è nel formato api://<application-client-id>. È anche possibile specificare un URI più leggibile, ad https://contoso.com/api esempio in base a uno dei domini verificati per il tenant. Per un'app multi-tenant, è necessario fornire un URI personalizzato. Per altre informazioni sui formati accettati per gli URI ID app, vedere le informazioni di riferimento sulle procedure consigliate per le registrazioni delle app.

  13. Seleziona Aggiungi un ambito.

    1. In Nome ambito immettere user_impersonation.
    2. In Chi può fornire il consenso selezionare Amministrazione e utenti se si vuole consentire agli utenti di fornire il consenso a questo ambito.
    3. Nelle caselle di testo immettere il nome dell'ambito del consenso e la descrizione da mostrare agli utenti nella pagina del consenso. Ad esempio, immettere Access <application-name>.
    4. Seleziona Aggiungi ambito.

  14. (Facoltativo) Per creare un segreto client:

    1. Nel riquadro di spostamento a sinistra selezionare Certificati e segreti>Segreti>client Nuovo segreto client.
    2. Immettere una descrizione e una scadenza e selezionare Aggiungi.
    3. Nel campo Valore copiare il valore del segreto client. Non verrà visualizzata di nuovo una volta che si esce da questa pagina.

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

  16. Completare la configurazione della registrazione dell'app:

    Non sono necessari altri passaggi per un tenant della forza lavoro.

Passaggio 2: Abilitare l'ID Microsoft Entra nell'app servizio app

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

  2. Nel riquadro di spostamento a sinistra selezionare Autenticazione>Aggiungi provider di>identità Microsoft.

  3. Selezionare il tipo di tenant della registrazione dell'app creata.

  4. Configurare l'app per l'uso della registrazione creata usando le istruzioni per il tipo di tenant appropriato:

    Per Tipo di registrazione dell'app scegliere una delle opzioni seguenti:

    • Selezionare una registrazione dell'app esistente in questa directory: scegliere una registrazione dell'app dal tenant corrente e raccogliere automaticamente le informazioni necessarie sull'app. Il sistema tenterà di creare un nuovo segreto client per la registrazione dell'app e di configurare automaticamente l'app per usarlo. Un URL dell'autorità di certificazione predefinito viene impostato in base ai tipi di account supportati configurati nella registrazione dell'app. Se si intende modificare questa impostazione predefinita, consultare la tabella seguente.
    • Specificare i dettagli di una registrazione dell'app esistente: specificare i dettagli per la registrazione di un'app da un altro tenant o se l'account non dispone dell'autorizzazione nel tenant corrente per eseguire query sulle registrazioni. Per questa opzione, è necessario compilare manualmente i valori di configurazione in base alla tabella seguente.

    L'endpointdi autenticazione per un tenant della forza lavoro deve essere un valore specifico per l'ambiente cloud. Ad esempio, un tenant della forza lavoro in Azure globale userebbe "https://login.microsoftonline.com" come endpoint di autenticazione. Prendere nota del valore dell'endpoint di autenticazione, perché è necessario per costruire l'URL dell'autorità di certificazione corretto.

    Quando si compilano direttamente i dettagli di configurazione, usare i valori raccolti durante il processo di creazione della registrazione dell'app:

    Campo Descrizione
    ID applicazione (client) Usare il valore di ID applicazione (client) della registrazione dell'app.
    Segreto client Usare il segreto client generato nella registrazione dell'app. Con un segreto client, viene usato il flusso ibrido e il servizio app restituirà i token di accesso e aggiornamento. Quando il segreto client non è impostato, viene usato il flusso implicito e viene restituito solo un token ID. Questi token vengono inviati dal provider e archiviati nell'archivio token di autenticazione servizio app.
    URL autorità di certificazione Usare <authentication-endpoint>/<tenant-id>/v2.0e sostituire< authentication-endpoint con l'endpoint>di autenticazione determinato nel passaggio precedente per il tipo di tenant e l'ambiente cloud, sostituendo< anche l'ID> tenant con l'IDdirectory (tenant) in cui è stata creata la registrazione dell'app. Per le applicazioni che usano Azure AD v1, omettere /v2.0 nell'URL.

    Questo valore viene usato per reindirizzare gli utenti al tenant Microsoft Entra corretto, nonché per scaricare i metadati appropriati per determinare ad esempio le chiavi di firma del token e il valore di attestazione dell'autorità di certificazione del token appropriato. Qualsiasi configurazione diversa da un endpoint specifico del tenant verrà considerata multi-tenant. Nelle configurazioni multi-tenant non viene eseguita alcuna convalida dell'emittente o dell'ID tenant dal sistema e questi controlli devono essere gestiti completamente nella logica di autorizzazione dell'app.
    Destinatari token consentiti Questo campo è facoltativo. L'ID applicazione (client) configurato viene sempre considerato implicitamente come gruppo di destinatari consentito. Se l'applicazione rappresenta un'API che verrà chiamata da altri client, è necessario aggiungere anche l'URI ID applicazione configurato nella registrazione dell'app. È previsto un limite di 500 caratteri nell'elenco dei gruppi di destinatari consentiti.

    Il segreto client verrà archiviato come impostazione dell'applicazione slot-sticky denominata MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. È possibile aggiornare questa impostazione in un secondo momento per usare i riferimenti a Key Vault se si vuole gestire il segreto in Azure Key Vault.

  5. Se si tratta del primo provider di identità configurato per l'applicazione, verrà visualizzata anche una sezione servizio app impostazioni di autenticazione. In caso contrario, è possibile passare al passaggio successivo.

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

  6. Selezionare Aggiungi.

È ora possibile usare Microsoft Identity Platform per l'autenticazione nell'app. Il provider verrà elencato nella schermata Autenticazione . Da qui è possibile modificare o eliminare questa configurazione del provider.

Autorizzare le richieste

Per impostazione predefinita, servizio app l'autenticazione gestisce solo l'autenticazione, determinando se il chiamante è chi dice di essere. L'autorizzazione, determinando se il chiamante deve avere accesso ad alcune risorse, è un passaggio aggiuntivo oltre l'autenticazione. Per altre informazioni su questi concetti, vedere Nozioni di base sull'autorizzazione di Microsoft Identity Platform.

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à emittente 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 le linee guida per Microsoft Identity Platform multi-tenant.

Eseguire convalide dal codice dell'applicazione

Quando si eseguono controlli di autorizzazione nel codice dell'app, è possibile sfruttare le informazioni sulle attestazioni che servizio app l'autenticazione rende disponibile. L'intestazione inserita x-ms-client-principal contiene un oggetto JSON con codifica Base64 con le attestazioni dichiarate 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, viene eseguito il mapping dell'attestazione tid a http://schemas.microsoft.com/identity/claims/tenantid .

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

Usare un criterio di autorizzazione predefinito

La registrazione dell'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, che è adatta a molte applicazioni. Tuttavia, 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. Tuttavia, per scenari comuni, 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 V2 servizio app. Attualmente, l'unico modo per configurare questi controlli predefiniti è tramite i modelli di Azure Resource Manager o l'API REST.

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

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Proprietà Descrizione
defaultAuthorizationPolicy Raggruppamento di requisiti che devono essere soddisfatti per accedere all'app. L'accesso viene concesso in base a una logica su ognuna AND delle proprietà configurate. Quando allowedApplications e allowedPrincipals sono configurati entrambi, la richiesta in ingresso deve soddisfare entrambi i requisiti per essere accettati.
allowedApplications Elenco consentito di ID client dell'applicazione stringa che rappresentano la risorsa client che sta chiamando nell'app. Quando questa proprietà è configurata come matrice non vuoto, verranno 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 le informazioni di riferimento sulle attestazioni di Microsoft Identity Platform.
allowedPrincipals Un raggruppamento di controlli che determinano se l'entità rappresentata dalla richiesta in ingresso può accedere all'app. La soddisfazione di allowedPrincipals si basa su una logica OR rispetto alle proprietà configurate.
identities (in allowedPrincipals) Elenco consentito di ID oggetto stringa che rappresentano utenti o applicazioni che hanno accesso. Quando questa proprietà è configurata come matrice non valida, il allowedPrincipals requisito può essere soddisfatto se l'utente o l'applicazione rappresentata dalla richiesta viene specificata nell'elenco. È previsto un limite di 500 caratteri nell'elenco delle identità.

Questo criterio valuta l'attestazione oid del token in ingresso. Vedere le informazioni di riferimento sulle attestazioni di Microsoft Identity Platform.

Inoltre, alcuni controlli possono essere configurati tramite un'impostazione dell'applicazione, indipendentemente dalla versione dell'API usata. 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, ad esempio "559a2f9c-c6f2-4d31-b8d6-5ad1a13f8330,5693f64a-3ad5-4be7-b846-e9d1141bcebcebc") per richiedere che il token in ingresso provena 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 . Questa impostazione viene ignorata e considerata come true se allowedPrincipals.identities è stata configurata (poiché l'attestazione oid viene verificata in base a questo elenco specificato di identità).

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

Configurare le app client per accedere alle servizio app

Nelle sezioni precedenti è stata registrata la servizio app o la funzione di Azure per autenticare gli utenti. Questa sezione illustra come registrare client nativi o app daemon in Microsoft Entra ID in modo che possano richiedere l'accesso alle API esposte dal servizio app per conto di utenti o utenti stessi, ad esempio in un'architettura a più livelli. Il completamento dei passaggi in questa sezione non è necessario se si vuole solo autenticare gli utenti.

Applicazione client nativa

È possibile registrare client nativi per richiedere l'accesso alle API dell'app servizio app per conto di un utente connesso.

  1. Dal menu del portale selezionare Microsoft Entra ID.

  2. Nel riquadro di spostamento a sinistra selezionare Registrazioni app> 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 (per dispositivi mobili 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 Autorizzazioni>API Aggiungi un'autorizzazione>API personali.

  8. Selezionare la registrazione creata in precedenza per l'app del servizio app. Se non viene visualizzata la registrazione dell'app, assicurarsi di aver aggiunto l'ambito user_impersonation in Creare una registrazione dell'app in MICROSOFT Entra ID per l'app servizio 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.

  1. Dal menu del portale selezionare Microsoft Entra ID.
  2. Nel riquadro di spostamento a sinistra selezionare 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 Certificati e segreti>Segreti>client Nuovo segreto client.
  8. Immettere una descrizione e una scadenza e selezionare Aggiungi.
  9. Nel campo Valore copiare il valore del segreto client. Non verrà visualizzata di nuovo una volta che si esce da questa pagina.

È ora possibile richiedere un token di accesso usando l'ID client e il segreto client impostando il parametro resource 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 e servizio app l'autenticazione convaliderà e userà il token come di consueto per indicare ora che il chiamante (in questo caso, non un utente) è autenticato.

Al momento, ciò 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 anche applicare l'autorizzazione per consentire solo determinate applicazioni client, è necessario eseguire alcune configurazioni aggiuntive.

  1. Definire un ruolo dell'app nel manifesto della registrazione dell'app che rappresenta il servizio app o l'app per le funzioni che si vuole proteggere.
  2. Nella registrazione app che rappresenta il client che deve essere autorizzato selezionare Autorizzazioni API>Aggiungi un'autorizzazione>API personali.
  3. Selezionare la registrazione app creata in precedenza. Se la registrazione app non è visualizzata, verificare di aver aggiunto un ruolo dell'app.
  4. In Autorizzazioni applicazione selezionare il ruolo dell'app creato in precedenza e quindi selezionare Aggiungi autorizzazioni.
  5. Assicurarsi di selezionare Concedi il consenso amministratore per autorizzare l'applicazione client a richiedere l'autorizzazione.
  6. Analogamente allo scenario precedente (prima dell'aggiunta di eventuali ruoli), è ora possibile richiedere un token di accesso per la stessa resource di destinazione e il token di accesso includerà un'attestazione roles contenente i ruoli dell'app autorizzati per l'applicazione client.
  7. 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 (questa operazione non viene eseguita dall'autenticazione servizio app). Per altre informazioni, vedere Accedere alle attestazioni utente.

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

Procedure consigliate

Indipendentemente dalla configurazione usata per configurare l'autenticazione, le procedure consigliate seguenti manterranno il tenant e le applicazioni più sicuri:

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

Eseguire la migrazione a Microsoft Graph

Alcune app meno recenti potrebbero anche essere state configurate con una dipendenza dal graph di Azure AD deprecato, che è pianificato per il ritiro completo. Ad esempio, il codice dell'app potrebbe aver chiamato 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 seguendo le indicazioni fornite da Microsoft Entra ID come parte del processo di deprecazione di Azure AD Graph. In seguito a queste istruzioni, 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 suffisso "/v2.0", se non è già stato fatto.

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

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

    È necessario rimuovere qualsiasi riferimento a "https://graph.windows.net", ad esempio. Questo include il resource parametro (che non è supportato dall'endpoint "/v2.0") o qualsiasi ambito richiesto specificamente da Azure AD Graph.

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

Con queste modifiche, quando servizio app l'autenticazione tenta di accedere, non richiederà più le autorizzazioni per Azure AD Graph e otterrà invece un token per Microsoft Graph. Qualsiasi uso di tale token dal codice dell'applicazione deve anche essere aggiornato, in base alle indicazioni fornite da Microsoft Entra ID.

Passaggi successivi