Come consentire l'accesso a qualsiasi utente di Azure Active Directory usando il modello di applicazione multi-tenantHow to sign in any Azure Active Directory user using the multi-tenant application pattern

Se si offre un'applicazione Software as a Service a molte organizzazioni, è possibile configurare l'applicazione per poter consentire accessi da qualsiasi tenant di Azure Active Directory (Azure AD).If you offer a Software as a Service application to many organizations, you can configure your application to accept sign-ins from any Azure Active Directory (AD) tenant. Questa configurazione viene definita impostazione dell'applicazione multi-tenant.This configuration is called making your application multi-tenant. Gli utenti in qualsiasi tenant Azure AD saranno in grado di accedere all'applicazione dopo il consenso ad usare il loro account con l'applicazione.Users in any Azure AD tenant will be able to sign in to your application after consenting to use their account with your application.

Se è disponibile un'applicazione esistente con un proprio sistema di account o che supporta altri tipi di accesso da altri provider di cloud, l'aggiunta dell'accesso di Azure AD da qualsiasi tenant è semplice.If you have an existing application that has its own account system, or supports other kinds of sign-ins from other cloud providers, adding Azure AD sign-in from any tenant is simple. Registrare l'app, aggiungere il codice di accesso tramite OAuth2, OpenID Connect o SAML e inserire un pulsante "Accedi con Microsoft" nell'applicazione.Just register your app, add sign-in code via OAuth2, OpenID Connect, or SAML, and put a "Sign In with Microsoft" button in your application.

Nota

Questo articolo presuppone che l'utente abbia già familiarità con la creazione di un'applicazione single-tenant per Azure AD.This article assumes you’re already familiar with building a single tenant application for Azure AD. In caso contrario, è consigliabile iniziare con una delle guide introduttive elencate nella home page della guida per gli sviluppatori.If you’re not, you should start with one of the quickstarts on the developer guide homepage.

Quattro semplici passaggi consentono di convertire l'applicazione in un'applicazione multi-tenant di Azure AD:There are four simple steps to convert your application into an Azure AD multi-tenant app:

  1. Aggiornare la registrazione dell'applicazione in modo che sia multi-tenantUpdate your application registration to be multi-tenant
  2. Aggiornare il codice per l'invio delle richieste all'endpoint /commonUpdate your code to send requests to the /common endpoint
  3. Aggiornare il codice per gestire più valori dell'autorità di certificazioneUpdate your code to handle multiple issuer values
  4. Informarsi sul consenso dell'utente e dell'amministratore e apportare le modifiche appropriate al codiceUnderstand user and admin consent and make appropriate code changes

Esaminiamo in dettaglio ogni passaggio.Let’s look at each step in detail. È anche possibile passare direttamente a questo elenco di esempi multi-tenant.You can also jump straight to this list of multi-tenant samples.

Aggiornare la registrazione in modo che sia multi-tenantUpdate registration to be multi-tenant

Per impostazione predefinita, le registrazioni di API o app Web in Azure AD sono single-tenant.By default, web app/API registrations in Azure AD are single tenant. Per rendere la registrazione multi-tenant, trovare l'opzione Multi-tenant nel riquadro Proprietà della registrazione dell'applicazione nel portale di Azure e impostarla su .You can make your registration multi-tenant by finding the Multi-Tenanted switch on the Properties pane of your application registration in the Azure portal and setting it to Yes.

Un'applicazione può diventare multi-tenant se l'URI dell'ID app dell'applicazione è univoco a livello globale.Before an application can be made multi-tenant, Azure AD requires the App ID URI of the application to be globally unique. L'URI dell'ID App è uno dei modi in cui un'applicazione viene identificata nei messaggi di protocollo.The App ID URI is one of the ways an application is identified in protocol messages. Per un'applicazione single-tenant, è sufficiente che l'URI dell'ID App sia univoco all'interno del tenant.For a single tenant application, it is sufficient for the App ID URI to be unique within that tenant. Per un'applicazione multi-tenant, è necessario che sia univoco a livello globale in modo da Azure AD possa trovare l'applicazione in tutti i tenant.For a multi-tenant application, it must be globally unique so Azure AD can find the application across all tenants. L'univocità globale viene applicata richiedendo che l'URI dell'ID App abbia un nome host corrispondente a un dominio verificato del tenant di Azure AD.Global uniqueness is enforced by requiring the App ID URI to have a host name that matches a verified domain of the Azure AD tenant. Per impostazione predefinita, le app create tramite il portale di Azure hanno un URI di ID app univoco a livello globale impostato al momento della creazione dell'app, ma è possibile modificare questo valore.By default, apps created via the Azure portal have a globally unique App ID URI set on app creation, but you can change this value.

Ad esempio, se il nome del tenant è contoso.onmicrosoft.com, l'URI ID app sarà https://contoso.onmicrosoft.com/myapp.For example, if the name of your tenant was contoso.onmicrosoft.com then a valid App ID URI would be https://contoso.onmicrosoft.com/myapp. Se il tenant ha un dominio verificato contoso.com, l'URI ID app valido sarà https://contoso.com/myapp.If your tenant had a verified domain of contoso.com, then a valid App ID URI would also be https://contoso.com/myapp. Se l'URI dell'ID App non segue questo modello, l'impostazione di un'applicazione come multi-tenant ha esito negativo.If the App ID URI doesn’t follow this pattern, setting an application as multi-tenant fails.

Nota

Per impostazione predefinita, le registrazioni client native e le applicazioni v2 sono multi-tenant.Native client registrations as well as v2 applications are multi-tenant by default. Non è necessario intraprendere alcuna azione per rendere multi-tenant queste registrazioni dell'applicazione.You don’t need to take any action to make these application registrations multi-tenant.

Aggiornare il codice per l'invio delle richieste all'endpoint /commonUpdate your code to send requests to /common

In un'applicazione single-tenant le richieste di accesso vengono inviate all'endpoint di accesso del tenant.In a single tenant application, sign-in requests are sent to the tenant’s sign-in endpoint. Ad esempio, per contoso.onmicrosoft.com l'endpoint sarà: https://login.microsoftonline.com/contoso.onmicrosoft.comFor example, for contoso.onmicrosoft.com the endpoint would be: https://login.microsoftonline.com/contoso.onmicrosoft.com

Le richieste inviate all'endpoint del tenant possono eseguire l'accesso degli utenti (o guest) in questo tenant alle applicazioni in questo tenant.Requests sent to a tenant’s endpoint can sign in users (or guests) in that tenant to applications in that tenant. Con un'applicazione multi-tenant, l'applicazione non determina in anticipo il tenant di provienienza dell'utente, pertanto non è possibile inviare richieste all'endpoint del tenant.With a multi-tenant application, the application doesn’t know up front what tenant the user is from, so you can’t send requests to a tenant’s endpoint. Al contrario, le richieste vengono inviate a un endpoint che esegue il multiplexing tra tutti i tenant di Azure Active Directory: https://login.microsoftonline.com/commonInstead, requests are sent to an endpoint that multiplexes across all Azure AD tenants: https://login.microsoftonline.com/common

Quando Azure AD riceve una richiesta sull'endpoint /common, consente l'accesso dell'utente e quindi individua il tenant di provenienza dell'utente.When Azure AD receives a request on the /common endpoint, it signs the user in and, as a consequence, discovers which tenant the user is from. L'endpoint /common funziona con tutti i protocolli di autenticazione supportati da Azure AD: OpenID Connect, OAuth 2.0, SAML 2.0 e WS-Federation.The /common endpoint works with all of the authentication protocols supported by Azure AD: OpenID Connect, OAuth 2.0, SAML 2.0, and WS-Federation.

La risposta di accesso all'applicazione di accesso contiene un token che rappresenta l'utente.The sign-in response to the application then contains a token representing the user. Il valore dell'autorità di certificazione nel token indica a un'applicazione il tenant di provenienza dell'utente.The issuer value in the token tells an application what tenant the user is from. Quando l'endpoint /common restituisce una risposta, il valore dell'autorità di certificazione nel token corrisponde al tenant dell'utente.When a response returns from the /common endpoint, the issuer value in the token corresponds to the user’s tenant.

Importante

L'endpoint /common non è un tenant o un'autorità di certificazione, ma è semplicemente un multiplexer.The /common endpoint is not a tenant and is not an issuer, it’s just a multiplexer. Quando si usa l'endpoint /common, è necessario aggiornare la logica dell'applicazione per la convalida dei token in modo da tenerne conto.When using /common, the logic in your application to validate tokens needs to be updated to take this into account.

Aggiornare il codice per gestire più valori dell'autorità di certificazioneUpdate your code to handle multiple issuer values

Le applicazioni Web e le API Web ricevono e convalidano i token da Azure AD.Web applications and web APIs receive and validate tokens from Azure AD.

Nota

Le applicazioni client native richiedono e ricevono i token da Azure AD e li inviano alle API in cui vengono convalidati.While native client applications request and receive tokens from Azure AD, they do so to send them to APIs, where they are validated. Le applicazioni native non convalidano i token e devono gestirli come opachi.Native applications do not validate tokens and must treat them as opaque.

Passiamo ora al modo in cui un'applicazione convalida i token ricevuti da Azure AD.Let’s look at how an application validates tokens it receives from Azure AD. Un'applicazione single-tenant prende in genere un valore dell'endpoint come:A single tenant application normally takes an endpoint value like:

https://login.microsoftonline.com/contoso.onmicrosoft.com

e lo usa per creare un URL di metadati, in questo caso OpenID Connect, come:and uses it to construct a metadata URL (in this case, OpenID Connect) like:

https://login.microsoftonline.com/contoso.onmicrosoft.com/.well-known/openid-configuration

per scaricare due informazioni critiche che vengono usate per convalidare i token: il valore dell'autorità di certificazione e le chiavi di firma del tenant.to download two critical pieces of information that are used to validate tokens: the tenant’s signing keys and issuer value. Ogni tenant di Azure AD ha un valore univoco dell'autorità di certificazione del formato:Each Azure AD tenant has a unique issuer value of the form:

https://sts.windows.net/31537af4-6d77-4bb9-a681-d2394888ea26/

dove il valore GUID è la versione sicura di ridenominazione dell'ID tenant del tenant.where the GUID value is the rename-safe version of the tenant ID of the tenant. Se si seleziona il collegamento dei metadati precedente per contoso.onmicrosoft.com, è possibile visualizzare il valore dell'autorità di certificazione nel documento.If you select the preceding metadata link for contoso.onmicrosoft.com, you can see this issuer value in the document.

Quando un'applicazione single-tenant convalida un token, controlla la firma del token con le chiavi di firma del documento di metadati.When a single tenant application validates a token, it checks the signature of the token against the signing keys from the metadata document. Questo test consente di verificare che il valore dell'autorità di certificazione nel token corrisponda a quello che è stato trovato nel documento di metadati.This test allows it to make sure the issuer value in the token matches the one that was found in the metadata document.

Poiché l'endpoint /common non corrisponde a un tenant e non è un'autorità di certificazione, il valore dell'autorità di certificazione nei metadati per /common ha un URL basato su modello invece di un valore effettivo:Because the /common endpoint doesn’t correspond to a tenant and isn’t an issuer, when you examine the issuer value in the metadata for /common it has a templated URL instead of an actual value:

https://sts.windows.net/{tenantid}/

Un'applicazione multi-tenant non può quindi convalidare i token semplicemente confrontando il valore dell'autorità di certificazione nei metadati con il valore issuer nel token.Therefore, a multi-tenant application can’t validate tokens just by matching the issuer value in the metadata with the issuer value in the token. Un'applicazione multi-tenant richiede una logica per decidere quali valori di autorità di certificazione sono validi in base alla parte ID del tenant del valore dell'autorità di certificazione.A multi-tenant application needs logic to decide which issuer values are valid and which are not based on the tenant ID portion of the issuer value.

Se ad esempio un'applicazione multi-tenant consente l'accesso solo da tenant specifici che hanno eseguito l'accesso ai servizi, è necessario verificare il valore dell'autorità di certificazione o il valore di attestazione tid nel token per assicurarsi che sia incluso nel relativo elenco di sottoscrittori.For example, if a multi-tenant application only allows sign-in from specific tenants who have signed up for their service, then it must check either the issuer value or the tid claim value in the token to make sure that tenant is in their list of subscribers. Se un'applicazione multi-tenant gestisce solo persone e non adotta decisioni di accesso basate su tenant, è possibile ignorare il valore dell'autorità di certificazione.If a multi-tenant application only deals with individuals and doesn’t make any access decisions based on tenants, then it can ignore the issuer value altogether.

Negli esempi multi-tenant la convalida dell'autorità di certificazione è disabilitata per consentire l'accesso a qualsiasi tenant di Azure AD.In the multi-tenant samples, issuer validation is disabled to enable any Azure AD tenant to sign in.

Per fare in modo che un utente possa accedere a un'applicazione in Azure AD, l'applicazione deve essere rappresentata nel tenant dell'utente.For a user to sign in to an application in Azure AD, the application must be represented in the user’s tenant. Ciò consente alle organizzazioni di eseguire operazioni come applicare criteri univoci quando gli utenti dal tenant accedono all'applicazione.This allows the organization to do things like apply unique policies when users from their tenant sign in to the application. Per un'applicazione single-tenant questa registrazione è semplice. È l'azione che viene eseguita quando si registra l'applicazione nel portale di Azure.For a single tenant application, this registration is simple; it’s the one that happens when you register the application in the Azure portal.

Per un'applicazione multi-tenant, la registrazione iniziale per l'applicazione si trova nel tenant di Azure AD usato dallo sviluppatore.For a multi-tenant application, the initial registration for the application lives in the Azure AD tenant used by the developer. Quando un utente di un tenant diverso accede all'applicazione per la prima volta, Azure AD richiede il consenso alle autorizzazioni richieste dall'applicazione.When a user from a different tenant signs in to the application for the first time, Azure AD asks them to consent to the permissions requested by the application. Se fornisce il consenso, viene creata una rappresentazione dell'applicazione denominata entità servizio nel tenant dell'utente ed è possibile procedere con l'accesso.If they consent, then a representation of the application called a service principal is created in the user’s tenant, and sign-in can continue. Viene anche creata una delega nella directory che registra il consenso dell'utente all'applicazione.A delegation is also created in the directory that records the user’s consent to the application. Per informazioni dettagliate sugli oggetti applicazione ed entità servizio dell'applicazione e su come interagiscono tra loro, vedere Oggetti applicazione e oggetti entità servizio.For details on the application's Application and ServicePrincipal objects, and how they relate to each other, see Application Objects and Service Principal Objects.

Consenso per l'app a livello singolo

Questa esperienza di consenso è interessata dalle autorizzazioni richieste dall'applicazione.This consent experience is affected by the permissions requested by the application. Azure AD supporta due tipi di autorizzazioni, delegate e solo app.Azure AD supports two kinds of permissions, app-only and delegated.

  • Un'autorizzazione delegata concede a un'applicazione la possibilità di agire come utente connesso per un sottoinsieme di operazioni che l'utente può eseguire.A delegated permission grants an application the ability to act as a signed in user for a subset of the things the user can do. Ad esempio, è possibile concedere a un'applicazione l'autorizzazione delegata per la lettura del calendario dell'utente connesso.For example, you can grant an application the delegated permission to read the signed in user’s calendar.
  • Un'autorizzazione solo app viene concessa direttamente all'identità dell'applicazione.An app-only permission is granted directly to the identity of the application. Ad esempio, è possibile concedere a un'applicazione l'autorizzazione solo app per leggere l'elenco di utenti in un tenant, indipendentemente dall'utente che ha eseguito l'accesso all'applicazione.For example, you can grant an application the app-only permission to read the list of users in a tenant, regardless of who is signed in to the application.

Alcune autorizzazioni possono essere concesse da un utente normale, mentre altre richiedono il consenso dell'amministratore tenant.Some permissions can be consented to by a regular user, while others require a tenant administrator’s consent.

Le autorizzazioni solo app richiedono il consenso dell'amministratore tenant.App-only permissions always require a tenant administrator’s consent. Se l'applicazione richiede un'autorizzazione solo per app e un utente tenta di accedere all'applicazione, viene visualizzato un messaggio di errore che informa che l'utente non è in grado di fornire il consenso.If your application requests an app-only permission and a user tries to sign in to the application, an error message is displayed saying the user isn’t able to consent.

Alcune autorizzazioni delegate richiedono anche il consenso dell'amministratore tenant.Certain delegated permissions also require a tenant administrator’s consent. Ad esempio, il writeback in Azure AD come utente connesso richiede il consenso dell'amministratore tenant.For example, the ability to write back to Azure AD as the signed in user requires a tenant administrator’s consent. Come le autorizzazioni solo app, se un utente comune tenta di accedere a un'applicazione che richiede un'autorizzazione delegata per la quale è necessario il consenso dell'amministratore, viene visualizzato un errore nell'applicazione.Like app-only permissions, if an ordinary user tries to sign in to an application that requests a delegated permission that requires administrator consent, your application receives an error. La richiesta del consenso di amministratore da parte di un'applicazione è determinata dallo sviluppatore che ha pubblicato la risorsa ed è presente nella documentazione per la risorsa.Whether a permission requires admin consent is determined by the developer that published the resource, and can be found in the documentation for the resource. La documentazione sulle autorizzazioni per l'API Graph di Azure AD e l'API Microsoft Graph indica quali autorizzazioni richiedono il consenso dell'amministratore.The permissions documentation for the Azure AD Graph API and Microsoft Graph API indicate which permissions require admin consent.

Se l'applicazione usa autorizzazioni che richiedono il consenso dell'amministratore, è necessario che sia presente un movimento, ad esempio un pulsante o un collegamento, con cui l'amministratore può avviare l'azione.If your application uses permissions that require admin consent, you need to have a gesture such as a button or link where the admin can initiate the action. La richiesta inviata dall'applicazione per questa azione è la richiesta di autorizzazione OAuth2/OpenID Connect standard, che include anche il parametro prompt=admin_consent della stringa di query.The request your application sends for this action is the usual OAuth2/OpenID Connect authorization request that also includes the prompt=admin_consent query string parameter. Dopo che l'amministratore ha fornito il consenso e l'entità servizio è stata creata nel tenant del cliente, le successive richieste di accesso non richiedono il parametro prompt=admin_consent.Once the admin has consented and the service principal is created in the customer’s tenant, subsequent sign-in requests do not need the prompt=admin_consent parameter. Poiché l'amministratore ha deciso che le autorizzazioni richieste sono accettabili, a nessun altro utente nel tenant viene richiesto il consenso da questo punto in poi.Since the administrator has decided the requested permissions are acceptable, no other users in the tenant are prompted for consent from that point forward.

Un amministratore tenant può disabilitare la possibilità che gli utenti normali possano il consenso alle applicazioni.A tenant administrator can disable the ability for regular users to consent to applications. Se questa funzionalità è disabilitata, è necessario usare il consenso dell'amministratore come obbligatorio sempre per l'applicazione nel tenant.If this capability is disabled, admin consent is always required for the application to be used in the tenant. Per testare l'applicazione con il consenso dell'utente finale disabilitato, è possibile trovare l'opzione di configurazione nel portale di Azure nella sezione Impostazioni utente sotto Applicazioni aziendali.If you want to test your application with end user consent disabled, you can find the configuration switch in the Azure portal in the User settings section under Enterprise applications.

Il parametro prompt=admin_consent può essere usato anche dalle applicazioni che richiedono autorizzazioni che non necessitano del consenso dell'amministratore.The prompt=admin_consent parameter can also be used by applications that request permissions that do not require admin consent. Questo parametro viene usato, ad esempio, quando l'applicazione richiede un'esperienza in cui il tenant amministratore "si iscrive" una volta e a nessun altro utente viene richiesto il consenso da tale punto in poi.An example of when this would be used is if the application requires an experience where the tenant admin “signs up” one time, and no other users are prompted for consent from that point on.

Se un'applicazione richiede il consenso dell'amministratore e un amministratore accede senza che il parametro prompt=admin_consent venga inviato, quando l'amministratore concede correttamente il consenso all'applicazione, il consenso sarà valido solo per l'account utente.If an application requires admin consent and an admin signs in without the prompt=admin_consent parameter being sent, when the admin successfully consents to the application it will apply only for their user account. Gli utenti normali non potranno ancora eseguire l'accesso o fornire il consenso all'applicazione.Regular users will still not be able to sign in or consent to the application. Questa funzionalità è utile se si vuole assegnare all'amministratore tenant la possibilità di esplorare l'applicazione prima di consentire l'accesso ad altri utenti.This feature is useful if you want to give the tenant administrator the ability to explore your application before allowing other users access.

Nota

Alcune applicazioni offrono un'esperienza in cui gli utenti normali sono inizialmente in grado di fornire il consenso e successivamente l'applicazione può coinvolgere l'amministratore e richiedere le autorizzazioni che necessitano del consenso dell'amministratore.Some applications want an experience where regular users are able to consent initially, and later the application can involve the administrator and request permissions that require admin consent. Non è attualmente possibile eseguire questa operazione con una registrazione di applicazione v1 in Azure AD. Usando invece l'endpoint v2 le applicazioni possono richiedere le autorizzazioni in fase di esecuzione invece che al momento della registrazione, abilitando questo scenario.There is no way to do this with a v1 application registration in Azure AD today; however, using the v2 endpoint allows applications to request permissions at runtime instead of at registration time, which enables this scenario. Per altre informazioni, vedere l'endpoint v2.For more information, see the v2 endpoint.

L'applicazione può avere più livelli, ognuno rappresentato dalla propria registrazione in Azure AD.Your application may have multiple tiers, each represented by its own registration in Azure AD. Un esempio è un'applicazione nativa che esegue una chiamata a un'API Web o un'applicazione Web che esegue una chiamata a un'API Web.For example, a native application that calls a web API, or a web application that calls a web API. In entrambi i casi, il client (app nativa o app Web) richiede le autorizzazioni per eseguire la chiamata alla risorsa (API Web).In both of these cases, the client (native app or web app) requests permissions to call the resource (web API). Per fare in modo il client venga autorizzato correttamente nel tenant del cliente, tutte le risorse a cui richiede le autorizzazioni devono esistere già nel tenant del cliente.For the client to be successfully consented into a customer’s tenant, all resources to which it requests permissions must already exist in the customer’s tenant. Se questa condizione non viene soddisfatta, Azure AD restituisce un errore indicante che prima deve essere aggiunta la risorsa.If this condition isn’t met, Azure AD returns an error that the resource must be added first.

Più livelli in un tenant singoloMultiple tiers in a single tenant

Può trattarsi di un problema se l'applicazione logica è costituita da due o più registrazioni di applicazioni, ad esempio un client e una risorsa separati.This can be a problem if your logical application consists of two or more application registrations, for example a separate client and resource. Come ottenere prima la risorsa nel tenant del cliente?How do you get the resource into the customer tenant first? Azure AD si occupa di questo caso, concedendo al client e alla risorsa l'autorizzazione in un unico passaggio.Azure AD covers this case by enabling client and resource to be consented in a single step. L'utente visualizza la somma totale delle autorizzazioni richieste dal client e dalla risorsa nella pagina del consenso.The user sees the sum total of the permissions requested by both the client and resource on the consent page. Per abilitare questo comportamento, la registrazione dell'applicazione della risorsa deve includere l'ID app del client come knownClientApplications nel manifesto dell'applicazione.To enable this behavior, the resource’s application registration must include the client’s App ID as a knownClientApplications in its application manifest. Ad esempio: For example:

knownClientApplications": ["94da0930-763f-45c7-8d26-04d5938baab2"]

Ciò viene illustrato in un client nativo multilivello che esegue la chiamata all'esempio di API Web nella sezione Contenuti correlati alla fine di questo articolo.This is demonstrated in a multi-tier native client calling web API sample in the Related content section at the end of this article. Il diagramma seguente fornisce una panoramica del consenso per un'app multilivello registrata in un singolo tenant.The following diagram provides an overview of consent for a multi-tier app registered in a single tenant.

Consenso per l'app client nota multilivello

Più livelli in tenant multipliMultiple tiers in multiple tenants

Un caso simile si verifica se i diversi livelli di un'applicazione vengono registrati in tenant diversi.A similar case happens if the different tiers of an application are registered in different tenants. Ad esempio, si consideri il caso della creazione di un'applicazione client nativa che esegue la chiamata all'API di Office 365 Exchange Online.For example, consider the case of building a native client application that calls the Office 365 Exchange Online API. Per sviluppare l'applicazione nativa e successivamente eseguire l'applicazione nativa nel tenant del cliente, è necessario che sia presente l'entità servizio Exchange Online.To develop the native application, and later for the native application to run in a customer’s tenant, the Exchange Online service principal must be present. In questo caso lo sviluppatore e il cliente devono acquistare Exchange Online per creare l'entità servizio nei tenant.In this case, the developer and customer must purchase Exchange Online for the service principal to be created in their tenants.

Nel caso di un'API creata da un'organizzazione diversa da Microsoft, lo sviluppatore dell'API deve includere un modo che consenta ai clienti di fornire il consenso per l'applicazione nei tenant dei clienti.In the case of an API built by an organization other than Microsoft, the developer of the API needs to provide a way for their customers to consent the application into their customers' tenants. La progettazione consigliata è per consentire allo sviluppatore di terze parti di compilare l'API in modo tale che possa fungere anche da client Web per implementare l'iscrizione.The recommended design is for the third party developer to build the API such that it can also function as a web client to implement sign-up. A tale scopo, effettuare l'operazione seguente:To do this:

  1. Seguire le sezioni precedenti per verificare che l'API implementi i requisiti del codice/registrazione dell'applicazione multi-tenant.Follow the earlier sections to ensure the API implements the multi-tenant application registration/code requirements.
  2. Oltre a esporre gli ambiti/ruoli dell'API, verificare che la registrazione comprenda l'autorizzazione di Azure AD "Accedi e leggi il profilo di un altro utente" (fornita per impostazione predefinita).In addition to exposing the API's scopes/roles, make sure the registration includes the "Sign in and read user profile" Azure AD permission (provided by default).
  3. Implementare una pagina di iscrizione/accesso nel client Web, seguendo le linee guida del consenso dell'amministratore descritte in precedenza.Implement a sign-in/sign-up page in the web client, following the admin consent guidance discussed earlier.
  4. Quando l'utente acconsente all'applicazione, vengono creati i collegamenti all'entità servizio e alla delega di consenso nel tenant e l'applicazione nativa può ottenere i token per l'API.Once the user consents to the application, the service principal and consent delegation links are created in their tenant, and the native application can get tokens for the API.

Il diagramma seguente fornisce una panoramica del consenso per un'app multilivello registrata in diversi tenant.The following diagram provides an overview of consent for a multi-tier app registered in different tenants.

Consenso per l'app di terze parti multilivello

Gli utenti e gli amministratori possono revocare il consenso all'applicazione in qualsiasi momento:Users and administrators can revoke consent to your application at any time:

Se un amministratore fornisce il consenso a un'applicazione per tutti gli utenti in un tenant, gli utenti non possono revocare l'accesso singolarmente.If an administrator consents to an application for all users in a tenant, users cannot revoke access individually. Solo l'amministratore può revocare l'accesso e soltanto per l'intera applicazione.Only the administrator can revoke access, and only for the whole application.

Applicazioni multi-tenant e memorizzazione nella cache dei token di accessoMulti-tenant applications and caching access tokens

Le applicazioni multi-tenant possono anche ottenere i token di accesso per eseguire chiamate alle API protette da Azure AD.Multi-tenant applications can also get access tokens to call APIs that are protected by Azure AD. Un errore comune quando si usa Active Directory Authentication Library (ADAL) con un'applicazione multi-tenant è quello di richiedere inizialmente un token per un utente tramite /common, ricevere una risposta e quindi richiedere un token successivo per lo stesso utente usando sempre /common.A common error when using the Active Directory Authentication Library (ADAL) with a multi-tenant application is to initially request a token for a user using /common, receive a response, then request a subsequent token for that same user also using /common. Poiché la risposta da Azure AD proviene da un tenant, non /common, la libreria ADAL memorizza nella cache il token come proveniente dal tenant.Because the response from Azure AD comes from a tenant, not /common, ADAL caches the token as being from the tenant. Nella chiamata successiva a /common per ottenere un token di accesso per l'utente non è presente la voce della cache e all'utente viene richiesto di accedere di nuovo.The subsequent call to /common to get an access token for the user misses the cache entry, and the user is prompted to sign in again. Per evitare questo errore della cache, assicurarsi che le chiamate successive per un utente già connesso vengano eseguite all'endpoint del tenant.To avoid missing the cache, make sure subsequent calls for an already signed in user are made to the tenant’s endpoint.

Passaggi successiviNext steps

Questo articolo ha illustrato come compilare un'applicazione che consente a un utente di accedere da qualsiasi tenant di Azure AD.In this article, you learned how to build an application that can sign in a user from any Azure AD tenant. Dopo aver abilitato l'accesso Single Sign-On (SSO) tra l'app e Azure AD, è anche possibile aggiornare l'applicazione per accedere alle API esposte dalle risorse di Microsoft, come Office 365.After enabling Single Sign-On (SSO) between your app and Azure AD, you can also update your application to access APIs exposed by Microsoft resources like Office 365. In questo modo è possibile offrire un'esperienza personalizzata nell'applicazione, ad esempio mostrando informazioni contestuali per gli utenti, come l'immagine del profilo o il successivo appuntamento nel calendario.This lets you offer a personalized experience in your application, such as showing contextual information to the users, like their profile picture or their next calendar appointment. Per altre informazioni sulle chiamate API ai servizi di Azure AD e Office 365 come Exchange, SharePoint, OneDrive, OneNote, Planner, Excel e altri ancora, vedere: API di Microsoft Graph.To learn more about making API calls to Azure AD and Office 365 services like Exchange, SharePoint, OneDrive, OneNote, Planner, Excel, and more, visit Microsoft Graph API.