Scenari di autenticazione per Azure ADAuthentication Scenarios for Azure AD

Azure Active Directory (AD) semplifica l'autenticazione per gli sviluppatori fornendo le identità come servizio, con il supporto per protocolli standard del settore come OAuth 2.0 e OpenID Connect, nonché librerie open source per diverse piattaforme che permettono di iniziare rapidamente a creare codice.Azure Active Directory (Azure AD) simplifies authentication for developers by providing identity as a service, with support for industry-standard protocols such as OAuth 2.0 and OpenID Connect, as well as open source libraries for different platforms to help you start coding quickly. Questo documento include informazioni utili per comprendere i diversi scenari supportati da Azure AD, oltre a illustrare come iniziare.This document will help you understand the various scenarios Azure AD supports and will show you how to get started. Il documento è suddiviso nelle sezioni seguenti:It’s divided into the following sections:

Nozioni di base sull'autenticazione in Azure AD.Basics of Authentication in Azure AD

Se non si ha familiarità con i concetti di base dell'autenticazione in Azure AD, leggere questa sezione.If you are unfamiliar with basic concepts of authentication in Azure AD, read this section. In caso contrario, è possibile passare alla sezione Scenari e tipi di applicazione.Otherwise, you may want to skip down to Application Types and Scenarios.

Si consideri lo scenario più semplice in cui è necessaria l'identità: un utente deve eseguire l'autenticazione a un'applicazione Web da un Web browser.Let’s consider the most basic scenario where identity is required: a user in a web browser needs to authenticate to a web application. Questo scenario è descritto più dettagliatamente nella sezione Da Web browser ad applicazione Web , ma è un punto di partenza utile per illustrare le funzionalità di Azure AD e definire i concetti relativi al funzionamento dello scenario.This scenario is described in greater detail in the Web Browser to Web Application section, but it’s a useful starting point to illustrate the capabilities of Azure AD and conceptualize how the scenario works. Per questo scenario considerare il diagramma seguente:Consider the following diagram for this scenario:

Panoramica dell'accesso all'applicazione Web

Tenendo presente il diagramma riportato sopra, ecco cosa occorre sapere sui vari componenti:With the diagram above in mind, here’s what you need to know about its various components:

  • Azure AD è il provider di identità, che si occupa della verifica dell'identità degli utenti e delle applicazioni presenti in una directory aziendale e infine rilascia i token di sicurezza, se l'autenticazione di tali utenti e applicazioni riesce.Azure AD is the identity provider, responsible for verifying the identity of users and applications that exist in an organization’s directory, and ultimately issuing security tokens upon successful authentication of those users and applications.
  • Un'applicazione per la quale è previsto l'outsourcing dell'autenticazione ad Azure AD deve essere registrata in Azure AD, che registra e identifica in modo univoco l'app nella directory.An application that wants to outsource authentication to Azure AD must be registered in Azure AD, which registers and uniquely identifies the app in the directory.
  • Gli sviluppatori possono usare le librerie di autenticazione open source di Azure AD per semplificare l'autenticazione gestendo direttamente i dettagli del protocollo.Developers can use the open source Azure AD authentication libraries to make authentication easy by handling the protocol details for you. Per altre informazioni, vedere Librerie di autenticazione di Azure Active Directory .See Azure Active Directory Authentication Libraries for more information.

• Dopo l'autenticazione di un utente, l'applicazione deve convalidare il token di sicurezza dell'utente per verificare che per l'autenticazione le parti previste sia riuscita.• Once a user has been authenticated, the application must validate the user’s security token to ensure that authentication was successful for the intended parties. Gli sviluppatori possono usare le librerie di autenticazione fornite per gestire la convalida dei token da Azure AD, inclusi i token Web JSON (JWT) o SAML 2.0.Developers can use the provided authentication libraries to handle validation of any token from Azure AD, including JSON Web Tokens (JWT) or SAML 2.0. Per eseguire manualmente la convalida, vedere la documentazione relativa al Gestore dei token JWT .If you want to perform validation manually, see the JWT Token Handler documentation.

Importante

Azure AD usa la crittografia a chiave pubblica per firmare i token e verificarne la validità.Azure AD uses public key cryptography to sign tokens and verify that they are valid. Per altre informazioni sulla logica richiesta nell'applicazione per assicurare che sia sempre aggiornata con le chiavi più recenti, vedere Informazioni importanti sul rollover della chiave di firma in Azure AD .See Important Information About Signing Key Rollover in Azure AD for more information on the necessary logic you must have in your application to ensure it’s always updated with the latest keys.

• Il flusso di richieste e risposte per il processo di autenticazione dipende dal protocollo di autenticazione in uso, ad esempio OAuth 2.0, OpenID Connect, WS-Federation o SAML 2.0.• The flow of requests and responses for the authentication process is determined by the authentication protocol that was used, such as OAuth 2.0, OpenID Connect, WS-Federation, or SAML 2.0. Questi protocolli sono descritti in dettaglio nell'argomento Protocolli di autenticazione di Azure Active Directory e nelle sezioni successive.These protocols are discussed in more detail in the Azure Active Directory Authentication Protocols topic and in the sections below.

Nota

Azure AD supporta gli standard OAuth 2.0 e OpenID Connect che fanno un uso intensivo dei token di connessione, inclusi quelli rappresentati come JWTAzure AD supports the OAuth 2.0 and OpenID Connect standards that make extensive use of bearer tokens, including bearer tokens represented as JWTs. Un token di connessione è un token di sicurezza leggero che consente al "portatore" di accedere a una risorsa protetta.A bearer token is a lightweight security token that grants the “bearer” access to a protected resource. In questo senso, per "portatore" si intende qualsiasi parte che sia in grado di presentare il token.In this sense, the “bearer” is any party that can present the token. Anche se il rilascio del token di connessione è condizionato dal completamento del processo di autenticazione in Azure AD, se non vengono adottate le misure necessarie per proteggere il token durante la trasmissione e l'archiviazione, è possibile che venga intercettato e usato da parti non autorizzate.Though a party must first authenticate with Azure AD to receive the bearer token, if the required steps are not taken to secure the token in transmission and storage, it can be intercepted and used by an unintended party. Molti token di sicurezza hanno meccanismi integrati per prevenire l'uso non autorizzato, ma i token di connessione ne sono sprovvisti e devono essere trasportati su un canale protetto, ad esempio Transport Layer Security (HTTPS).While some security tokens have a built-in mechanism for preventing unauthorized parties from using them, bearer tokens do not have this mechanism and must be transported in a secure channel such as transport layer security (HTTPS). Se un token di connessione viene trasmesso senza essere protetto, un utente malintenzionato potrebbe usare un attacco "man in the middle" per acquisire il token e usarlo per l'accesso non autorizzato a una risorsa protetta.If a bearer token is transmitted in the clear, a man-in the middle attack can be used by a malicious party to acquire the token and use it for an unauthorized access to a protected resource. Gli stessi principi di sicurezza si applicano quando un token di connessione viene archiviato o memorizzato nella cache per un uso futuro.The same security principles apply when storing or caching bearer tokens for later use. Assicurarsi sempre che l'applicazione trasmetta ed archivi i token di connessione in modo sicuro.Always ensure that your application transmits and stores bearer tokens in a secure manner. Per altre considerazioni sulla sicurezza dei token di connessione, vedere la sezione 5 della specifica RFC 6750.For more security considerations on bearer tokens, see RFC 6750 Section 5.

Dopo avere delineato i concetti di base, è possibile passare alle sezioni seguenti per comprendere il funzionamento del provisioning in Azure AD e gli scenari comuni supportati da Azure AD.Now that you have an overview of the basics, read the sections below to understand how provisioning works in Azure AD and the common scenarios Azure AD supports.

Attestazioni nei token di sicurezza di Azure ADClaims in Azure AD Security Tokens

I token di sicurezza emessi da Azure AD contengono attestazioni o asserzioni di informazioni sull'oggetto autenticato.Security tokens issued by Azure AD contain claims, or assertions of information about the subject that has been authenticated. L'applicazione può usare tali attestazioni per varie attività.These claims can be used by the application for various tasks. Ad esempio, possono essere usate per convalidare il token, identificare il tenant di directory dell'oggetto, visualizzare informazioni relative all'utente, determinare l'autorizzazione dell'oggetto e così via.For example, they can be used to validate the token, identify the subject's directory tenant, display user information, determine the subject's authorization, and so on. Le attestazioni presenti in un determinato token di sicurezza dipendono dal tipo di token, dal tipo di credenziali usate per autenticare l'utente e dalla configurazione dell'applicazione.The claims present in any given security token are dependent upon the type of token, the type of credential used to authenticate the user, and the application configuration. La tabella seguente fornisce una breve descrizione dei tipi di attestazione generati da Azure AD.A brief description of each type of claim emitted by Azure AD is provided in the table below. Per altre informazioni, fare riferimento a Token e tipi di attestazioni supportati.For more information, refer to Supported Token and Claim Types.

AttestazioneClaim DescrizioneDescription
ID applicazioneApplication ID Identifica l'applicazione che usa il token.Identifies the application that is using the token.
DestinatariAudience Identifica la risorsa di destinazione del token.Identifies the recipient resource the token is intended for.
Riferimento alla classe contesto di autenticazione applicazioneApplication Authentication Context Class Reference Indica la modalità di autenticazione del client (client pubblico e client riservato).Indicates how the client was authenticated (public client vs. confidential client).
Istante di autenticazioneAuthentication Instant Registra la data e l'ora in cui è avvenuta l'autenticazione.Records the date and time when the authentication occurred.
Metodo di autenticazioneAuthentication Method Indica la modalità di autenticazione dell'oggetto del token (password, certificato e così via).Indicates how the subject of the token was authenticated (password, certificate, etc.).
NomeFirst Name Fornisce il nome dell'utente come è impostato in Azure AD.Provides the given name of the user as set in Azure AD.
GruppiGroups Contiene gli ID oggetto dei gruppi di Azure AD di cui l'utente è membro.Contains object Ids of Azure AD groups the user is a member of.
Provider di identitàIdentity Provider Registra il provider di identità che ha autenticato l'oggetto del token.Records the identity provider that authenticated the subject of the token.
Issued AtIssued At Registra l'ora in cui il token è stato emesso. Spesso usata per l'aggiornamento del token.Records the time at which the token was issued, often used for token freshness.
IssuerIssuer Identifica il servizio token di sicurezza che ha emesso il token, nonché il tenant di Azure AD.Identifies the STS that emitted the token as well as the Azure AD tenant.
CognomeLast Name Fornisce il cognome dell'utente come è impostato in Azure AD.Provides the surname of the user as set in Azure AD.
NomeName Fornisce un valore leggibile che identifica l'oggetto del token.Provides a human readable value that identifies the subject of the token.
ID oggettoObject Id Contiene un identificatore univoco e non modificabile dell'oggetto in Azure AD.Contains an immutable, unique identifier of the subject in Azure AD.
RuoliRoles Contiene i nomi descrittivi dei ruoli applicazione di Azure AD concessi all'utente.Contains friendly names of Azure AD Application Roles that the user has been granted.
ScopeScope Indica le autorizzazioni concesse all'applicazione client.Indicates the permissions granted to the client application.
OggettoSubject Indica l'entità su cui il token rilascia informazioni.Indicates the principal about which the token asserts information.
ID tenantTenant Id Contiene un identificatore univoco e non modificabile del tenant di directory che ha emesso il token.Contains an immutable, unique identifier of the directory tenant that issued the token.
Durata del tokenToken Lifetime Definisce l'intervallo di tempo entro il quale un token è valido.Defines the time interval within which a token is valid.
Nome dell'entità utenteUser Principal Name Contiene il nome dell'entità utente dell'oggetto.Contains the user principal name of the subject.
VersioneVersion Contiene il numero di versione del token.Contains the version number of the token.

Nozioni di base sulla registrazione di un'applicazione in Azure AD Basics of Registering an Application in Azure AD

Le applicazioni che usano l'outsourcing per l'autenticazione ad Azure AD devono essere registrate in una directory.Any application that outsources authentication to Azure AD must be registered in a directory. Questo passaggio include la comunicazione ad Azure AD delle informazioni sull'applicazione, compresi l'URL in cui si trova, l'URL per l'invio delle risposte dopo l'autenticazione, l'URI per identificare l'applicazione e così via.This step involves telling Azure AD about your application, including the URL where it’s located, the URL to send replies after authentication, the URI to identify your application, and more. Queste informazioni sono necessarie per alcune ragioni fondamentali:This information is required for a few key reasons:

  • Azure AD ha bisogno delle coordinate per comunicare con l'applicazione durante la gestione dell'accesso o lo scambio di token,Azure AD needs coordinates to communicate with the application when handling sign-on or exchanging tokens. tra cui:These include the following:

    • URI ID applicazione: l'identificatore di un'applicazione.Application ID URI: The identifier for an application. Questo valore viene inviato ad Azure AD durante l'autenticazione per specificare le applicazioni per cui il chiamante richiede un token.This value is sent to Azure AD during authentication to indicate which application the caller wants a token for. Questo valore è inoltre incluso nel token per indicare all'applicazione che era la destinazione prevista.Additionally, this value is included in the token so that the application knows it was the intended target.
    • URL di risposta e URI di reindirizzamento: nel caso di un'API Web o di un'applicazione Web, l'URL di risposta è il percorso a cui Azure AD invierà la risposta di autenticazione, compreso un token se l'autenticazione è riuscita.Reply URL and Redirect URI: In the case of a web API or web application, the Reply URL is the location to which Azure AD will send the authentication response, including a token if authentication was successful. Nel caso di un'applicazione nativa, l'URI di reindirizzamento è un identificatore univoco a cui Azure AD reindirizzerà l'agente utente in una richiesta OAuth 2.0.In the case of a native application, the Redirect URI is a unique identifier to which Azure AD will redirect the user-agent in an OAuth 2.0 request.
    • ID applicazione: l'ID di un'applicazione, che viene generato da Azure AD quando l'applicazione viene registrata.Application ID: The ID for an application, which is generated by Azure AD when the application is registered. Quando viene richiesto un codice di autorizzazione o token, l'ID applicazione e la chiave vengono inviati ad Azure AD durante l'autenticazione.When requesting an authorization code or token, the Application ID and key are sent to Azure AD during authentication.
    • Chiave: la chiave inviata insieme a un ID applicazione durante l'autenticazione ad Azure AD per chiamare un'API Web.Key: The key that is sent along with a Application ID when authenticating to Azure AD to call a web API.
  • Azure AD deve assicurarsi che l'applicazione disponga delle autorizzazioni necessarie per accedere ai dati della directory, ad altre applicazioni nell'organizzazione e così via.Azure AD needs to ensure the application has the required permissions to access your directory data, other applications in your organization, and so on

Per comprendere meglio il provisioning, è utile chiarire che esistono due categorie di applicazioni che possono essere sviluppate e integrate con Azure AD:Provisioning becomes clearer when you understand that there are two categories of applications that can be developed and integrated with Azure AD:

  • Applicazione con un singolo tenant: un'applicazione con un singolo tenant è destinata all'uso in una organizzazione.Single tenant application: A single tenant application is intended for use in one organization. In genere si tratta di applicazioni line-of-business scritte da uno sviluppatore aziendale.These are typically line-of-business (LoB) applications written by an enterprise developer. Un'applicazione con un singolo tenant deve essere accessibile solo agli utenti di una directory e quindi è necessario eseguirne il provisioning in una sola directory.A single tenant application only needs to be accessed by users in one directory, and as a result, it only needs to be provisioned in one directory. Queste applicazioni sono generalmente registrate da uno sviluppatore dell'organizzazione.These applications are typically registered by a developer in the organization.
  • Applicazione multi-tenant: un'applicazione multi-tenant è destinata all'uso in molte organizzazioni, non solo in una.Multi-tenant application: A multi-tenant application is intended for use in many organizations, not just one organization. Si tratta generalmente di applicazioni SaaS (Software-as-a-Service) scritte da un fornitore di software indipendente (ISV).These are typically software-as-a-service (SaaS) applications written by an independent software vendor (ISV). È necessario eseguire il provisioning delle applicazioni multi-tenant in ogni directory in cui verranno usate ed è richiesto il consenso dell'utente o dell'amministratore per registrarle.Multi-tenant applications need to be provisioned in each directory where they will be used, which requires user or administrator consent to register them. Questo processo di consenso inizia quando un'applicazione viene registrata nella directory e può accedere all'API Graph o magari a un'altra API Web.This consent process starts when an application has been registered in the directory and is given access to the Graph API or perhaps another web API. Quando un utente o amministratore di un'altra organizzazione esegue l'accesso per usare l'applicazione, viene visualizzata una finestra di dialogo in cui sono indicate le autorizzazioni richieste dall'applicazione.When a user or administrator from a different organization signs up to use the application, they are presented with a dialog that displays the permissions the application requires. L'utente o amministratore può quindi concedere il consenso all'applicazione, in modo da fornirle l'accesso ai dati indicati e infine di registrarla nella propria directory.The user or administrator can then consent to the application, which gives the application access to the stated data, and finally registers the application in their directory. Per altre informazioni, vedere Panoramica del framework di consenso.For more information, see Overview of the Consent Framework.

Quando si sviluppa un'applicazione multi-tenant invece di un'applicazione con un singolo tenant, occorre considerare qualche altro aspetto.Some additional considerations arise when developing a multi-tenant application instead of a single tenant application. Ad esempio, se l'applicazione viene resa disponibile agli utenti in più directory, è necessario un meccanismo per determinare il tenant attivo.For example, if you are making your application available to users in multiple directories, you need a mechanism to determine which tenant they’re in. Un'applicazione con un singolo tenant deve solo cercare un utente nella propria directory, mentre un'applicazione multi-tenant deve identificare un utente specifico in tutte le directory in Azure AD.A single tenant application only needs to look in its own directory for a user, while a multi-tenant application needs to identify a specific user from all the directories in Azure AD. A questo scopo, Azure AD fornisce un endpoint di autenticazione comune in cui qualsiasi applicazione multi-tenant può indirizzare le richieste di accesso, invece di un endpoint specifico di un tenant.To accomplish this task, Azure AD provides a common authentication endpoint where any multi-tenant application can direct sign-in requests, instead of a tenant-specific endpoint. Questo endpoint è https://login.microsoftonline.com/common per tutte le directory in Azure AD, mentre un endpoint specifico del tenant potrebbe essere https://login.microsoftonline.com/contoso.onmicrosoft.com. L'endpoint comune deve essere valutato con particolare attenzione durante lo sviluppo di un'applicazione, perché occorrerà la logica necessaria per gestire più tenant durante l'accesso, la disconnessione e la convalida dei token.This endpoint is https://login.microsoftonline.com/common for all directories in Azure AD, whereas a tenant-specific endpoint might be https://login.microsoftonline.com/contoso.onmicrosoft.com. The common endpoint is especially important to consider when developing your application because you’ll need the necessary logic to handle multiple tenants during sign-in, sign-out, and token validation.

Se si sviluppa un'applicazione con un singolo tenant, ma si intende metterla a disposizione di molte organizzazioni, è possibile modificare facilmente l'applicazione e la relativa configurazione in Azure AD per fare in modo che supporti più tenant.If you are currently developing a single tenant application but want to make it available to many organizations, you can easily make changes to the application and its configuration in Azure AD to make it multi-tenant capable. Azure AD usa inoltre la stessa chiave di firma per tutti i token in tutte le directory, a prescindere dal fatto che si fornisca l'autenticazione in un'applicazione con un singolo tenant o multi-tenant.In addition, Azure AD uses the same signing key for all tokens in all directories, whether you are providing authentication in a single tenant or multi-tenant application.

Ogni scenario indicati in questo documento include una sottosezione in cui sono descritti i relativi requisiti di provisioning.Each scenario listed in this document includes a sub-section that describes its provisioning requirements. Per informazioni più dettagliate sul provisioning di un'applicazione in Azure AD e sulle differenze tra applicazioni con un singolo tenant e applicazioni multi-tenant, vedere Applicazioni di integrazione con Azure Active Directory .For more in-depth information about provisioning an application in Azure AD and the differences between single and multi-tenant applications, see Integrating Applications with Azure Active Directory for more information. Di seguito sono illustrati gli scenari di applicazione più comuni in Azure AD.Continue reading to understand the common application scenarios in Azure AD.

Scenari e tipi di applicazioneApplication Types and Scenarios

Tutti gli scenari descritti in questo documento possono essere sviluppati con vari linguaggi e piattaforme.Each of the scenarios described in this document can be developed using various languages and platforms. Sono tutti supportati da esempi di codice completo disponibili nella guida agli esempi di codice o direttamente dal corrispondente archivio di esempio GitHub.They are all backed by complete code samples which are available in our Code Samples guide, or directly from the corresponding GitHub sample repositories. Inoltre, se l'applicazione necessita di una parte o di un segmento specifico di uno scenario end-to-end, nella maggior parte dei casi è possibile aggiungere tale funzionalità in modo indipendente.In addition, if your application needs a specific piece or segment of an end-to-end scenario, in most cases that functionality can be added independently. Ad esempio, se si ha un'applicazione nativa che chiama un'API Web, è possibile aggiungere facilmente un'applicazione Web che chiama la stessa API Web.For example, if you have a native application that calls a web API, you can easily add a web application that also calls the web API. Il diagramma seguente illustra questi scenari e tipi di applicazione e viene indicato come aggiungere i vari componenti:The following diagram illustrates these scenarios and application types, and how different components can be added:

Scenari e tipi di applicazione

Azure AD supporta i cinque scenari di applicazione principali descritti di seguito:These are the five primary application scenarios supported by Azure AD:

Da Web browser ad applicazione WebWeb Browser to Web Application

Questa sezione descrive un'applicazione che autentica un utente in un Web browser per un'applicazione Web.This section describes an application that authenticates a user in a web browser to a web application. In questo scenario l'applicazione Web indirizza il browser dell'utente per l'accesso ad Azure AD.In this scenario, the web application directs the user’s browser to sign them in to Azure AD. Tramite il browser dell'utente Azure AD restituisce una risposta di accesso che contiene attestazioni sull'utente in un token di sicurezza.Azure AD returns a sign-in response through the user’s browser, which contains claims about the user in a security token. Questo scenario supporta l'accesso mediante i protocolli WS-Federation, SAML 2.0 e OpenID Connect.This scenario supports sign-on using the WS-Federation, SAML 2.0, and OpenID Connect protocols.

DiagrammaDiagram

Flusso di autenticazione da browser ad applicazione Web

Descrizione del flusso del protocolloDescription of Protocol Flow

  1. Quando un utente visita l'applicazione e deve eseguire l'accesso, viene reindirizzato tramite una richiesta di accesso all'endpoint di autenticazione in Azure AD.When a user visits the application and needs to sign in, they are redirected via a sign-in request to the authentication endpoint in Azure AD.
  2. L'utente accede nella pagina di accesso.The user signs in on the sign-in page.
  3. Se l'autenticazione riesce, Azure AD crea un token di autenticazione e restituisce una risposta di accesso all'URL di risposta dell'applicazione configurato nel Portale di Azure.If authentication is successful, Azure AD creates an authentication token and returns a sign-in response to the application’s Reply URL that was configured in the Azure Portal. Per un'applicazione di produzione, questo URL di risposta deve essere HTTPS.For a production application, this Reply URL should be HTTPS. Il token restituito include le attestazioni sull'utente e Azure AD richieste dall'applicazione per convalidare il token.The returned token includes claims about the user and Azure AD that are required by the application to validate the token.
  4. L'applicazione convalida il token usando le informazioni sulla chiave di firma pubblica e sull'autorità emittente disponibili nel documento metadati federazione per Azure AD.The application validates the token by using a public signing key and issuer information available at the federation metadata document for Azure AD. Dopo la convalida del token da parte dell'applicazione, Azure AD avvia una nuova sessione con l'utente.After the application validates the token, Azure AD starts a new session with the user. La sessione consente all'utente di accedere all'applicazione fino alla scadenza.This session allows the user to access the application until it expires.

Esempi di codiceCode Samples

Vedere gli esempi di codice per gli scenari Da Web Browser ad applicazione Web.See the code samples for Web Browser to Web Application scenarios. Consultare spesso questa pagina perché vengono aggiunti regolarmente nuovi esempi.And, check back frequently -- we add new samples all the time. Da Web browser ad applicazione Web.Web Browser to Web Application.

RegistrazioneRegistering

  • Singolo tenant: se si crea un'applicazione solo per la propria organizzazione, è necessario registrarla nella directory aziendale tramite il Portale di Azure.Single Tenant: If you are building an application just for your organization, it must be registered in your company’s directory by using the Azure Portal.
  • Multi-tenant: se si crea un'applicazione che può essere usata da utenti esterni all'organizzazione, è necessario registrarla nella directory aziendale, ma anche nella directory delle singole organizzazioni che useranno l'applicazione.Multi-Tenant: If you are building an application that can be used by users outside your organization, it must be registered in your company’s directory, but also must be registered in each organization’s directory that will be using the application. Per rendere disponibile l'applicazione nella propria directory, è possibile includere un processo di accesso per i clienti che permetta loro di concedere il consenso all'applicazione.To make your application available in their directory, you can include a sign-up process for your customers that enables them to consent to your application. Al momento dell'iscrizione all'applicazione, viene visualizzata una finestra di dialogo in cui sono indicate le autorizzazioni richieste dall'applicazione e quindi viene presentata l'opzione per il consenso.When they sign up for your application, they will be presented with a dialog that shows the permissions the application requires, and then the option to consent. A seconda delle autorizzazioni richieste, è possibile che il consenso debba essere fornito da un amministratore dell'altra organizzazione.Depending on the required permissions, an administrator in the other organization may be required to give consent. Quando l'utente o l'amministratore acconsente, l'applicazione viene registrata nella directory.When the user or administrator consents, the application is registered in their directory. Per ulteriori informazioni, vedere Integrazione di applicazioni con Azure Active Directory.For more information, see Integrating Applications with Azure Active Directory.

Scadenza del tokenToken Expiration

La sessione dell'utente scade al termine del periodo di validità del token emesso da Azure AD.The user’s session expires when the lifetime of the token issued by Azure AD expires. Se necessario, l'applicazione può abbreviare questo periodo di validità, ad esempio disconnettendo gli utenti dopo un determinato tempo di inattività.Your application can shorten this time period if desired, such as signing out users based on a period of inactivity. Quando la sessione scade, all'utente viene chiesto di accedere di nuovo.When the session expires, the user will be prompted to sign in again.

Applicazione a singola pagina (SPA)Single Page Application (SPA)

Questa sezione descrive l'autenticazione per un'applicazione a pagina singola che utilizza Azure AD e la concessione di autorizzazione implicita OAuth 2.0 per proteggere il back-end dell'API Web.This section describes authentication for a Single Page Application, that uses Azure AD and the OAuth 2.0 implicit authorization grant to secure its web API back end. Le applicazioni a singola pagina sono in genere strutturate come un livello di presentazione JavaScript (front-end) eseguito nel browser e un back-end dell'API Web eseguito in un server e che implementa la logica di business dell'applicazione.Single Page Applications are typically structured as a JavaScript presentation layer (front end) that runs in the browser and a Web API back end that runs on a server and implements the application’s business logic. Per ulteriori informazioni sulla concessione di autorizzazione implicita e per stabilire se sia adatta allo scenario della propria applicazione, vedere Informazioni sul flusso di concessione implicita OAuth2 in Azure Active Directory.To learn more about the implicit authorization grant, and help you decide whether it's right for your application scenario, see Understanding the OAuth2 implicit grant flow in Azure Active Directory.

In questo scenario, quando l'utente accede, il front-end JavaScript utilizza Active Directory Authentication Library per JavaScript (ADAL.JS) e la concessione di autorizzazione implicita per ottenere un token ID (id_token) da Azure AD.In this scenario, when the user signs in, the JavaScript front end uses Active Directory Authentication Library for JavaScript (ADAL.JS) and the implicit authorization grant to obtain an ID token (id_token) from Azure AD. Il token viene memorizzato nella cache e il client lo associa alla richiesta come token di connessione quando si effettuano chiamate al relativo back-end dell'API Web, protetto tramite il middleware OWIN.The token is cached and the client attaches it to the request as the bearer token when making calls to its Web API back end, which is secured using the OWIN middleware.

DiagrammaDiagram

Diagramma Applicazione a singola pagina (SPA)

Descrizione del flusso del protocolloDescription of Protocol Flow

  1. L'utente passa all'applicazione Web.The user navigates to the web application.
  2. L'applicazione restituisce al browser il front-end JavaScript (livello di presentazione).The application returns the JavaScript front end (presentation layer) to the browser.
  3. L'utente avvia l'accesso, ad esempio facendo clic su un collegamento di accesso.The user initiates sign in, for example by clicking a sign in link. Il browser invia una richiesta GET all'endpoint di autorizzazione di Azure AD per richiedere un token ID.The browser sends a GET to the Azure AD authorization endpoint to request an ID token. Nei parametri di query di questa richiesta sono inclusi l'URL di risposta e l'ID applicazione.This request includes the application ID and reply URL in the query parameters.
  4. Azure AD convalida l'URL di risposta confrontandolo con l'URL di risposta registrato, configurato nel Portale di Azure.Azure AD validates the Reply URL against the registered Reply URL that was configured in the Azure Portal.
  5. L'utente accede nella pagina di accesso.The user signs in on the sign-in page.
  6. Se l'autenticazione riesce, Azure AD crea un token ID e lo restituisce come frammento di URL (#) all'URL di risposta dell'applicazione.If authentication is successful, Azure AD creates an ID token and returns it as a URL fragment (#) to the application’s Reply URL. Per un'applicazione di produzione, questo URL di risposta deve essere HTTPS.For a production application, this Reply URL should be HTTPS. Il token restituito include le attestazioni sull'utente e Azure AD richieste dall'applicazione per convalidare il token.The returned token includes claims about the user and Azure AD that are required by the application to validate the token.
  7. Il codice client di JavaScript in esecuzione nel browser estrae il token dalla risposta per usarlo nella protezione delle chiamate al back-end dell'API Web dell'applicazione.The JavaScript client code running in the browser extracts the token from the response to use in securing calls to the application’s web API back end.
  8. Il browser chiama il back-end dell'API Web dell'applicazione con il token di accesso nell'intestazione dell'autorizzazione.The browser calls the application’s web API back end with the access token in the authorization header.

Esempi di codiceCode Samples

Vedere gli esempi di codice per gli scenari di applicazioni a singola pagina (SPA).See the code samples for Single Page Application (SPA) scenarios. Assicurarsi di consultare spesso questa pagina perché vengono aggiunti regolarmente nuovi esempi.Be sure to check back frequently -- we add new samples all the time. Applicazione a singola pagina (SPA).Single Page Application (SPA).

RegistrazioneRegistering

  • Singolo tenant: se si crea un'applicazione solo per la propria organizzazione, è necessario registrarla nella directory aziendale tramite il Portale di Azure.Single Tenant: If you are building an application just for your organization, it must be registered in your company’s directory by using the Azure Portal.
  • Multi-tenant: se si crea un'applicazione che può essere usata da utenti esterni all'organizzazione, è necessario registrarla nella directory aziendale, ma anche nella directory delle singole organizzazioni che useranno l'applicazione.Multi-Tenant: If you are building an application that can be used by users outside your organization, it must be registered in your company’s directory, but also must be registered in each organization’s directory that will be using the application. Per rendere disponibile l'applicazione nella propria directory, è possibile includere un processo di accesso per i clienti che permetta loro di concedere il consenso all'applicazione.To make your application available in their directory, you can include a sign-up process for your customers that enables them to consent to your application. Al momento dell'iscrizione all'applicazione, viene visualizzata una finestra di dialogo in cui sono indicate le autorizzazioni richieste dall'applicazione e quindi viene presentata l'opzione per il consenso.When they sign up for your application, they will be presented with a dialog that shows the permissions the application requires, and then the option to consent. A seconda delle autorizzazioni richieste, è possibile che il consenso debba essere fornito da un amministratore dell'altra organizzazione.Depending on the required permissions, an administrator in the other organization may be required to give consent. Quando l'utente o l'amministratore acconsente, l'applicazione viene registrata nella directory.When the user or administrator consents, the application is registered in their directory. Per ulteriori informazioni, vedere Integrazione di applicazioni con Azure Active Directory.For more information, see Integrating Applications with Azure Active Directory.

Dopo la registrazione dell'applicazione, è necessario configurarla per l'uso del protocollo di concessione implicita OAuth 2.0.After registering the application, it must be configured to use OAuth 2.0 Implicit Grant protocol. Per impostazione predefinita, questo protocollo è disabilitato per le applicazioni.By default, this protocol is disabled for applications. Per abilitare il protocollo di concessione implicita OAuth2 per l'applicazione, modificare il manifesto dell'applicazione dal Portale di Azure e impostare il valore "oauth2AllowImplicitFlow" su vero.To enable the OAuth2 Implicit Grant protocol for your application, edit its application manifest from the Azure Portal and set the “oauth2AllowImplicitFlow” value to true. Per istruzioni dettagliare, vedere la sezione relativa all' abilitazione della concessione implicita OAuth 2.0 per le applicazioni a singola pagina.For detailed instructions, see Enabling OAuth 2.0 Implicit Grant for Single Page Applications.

Scadenza del tokenToken Expiration

Quando si usa ADAL.js per gestire l'autenticazione con Azure AD, è possibile sfruttare i vantaggi offerti da varie funzionalità che facilitano l'aggiornamento di un token scaduto e consentono di ottenere token per risorse API Web aggiuntive che possono essere chiamate dall'applicazione.When you use ADAL.js to manage authentication with Azure AD, you benefit from several features that facilitate refreshing an expired token as well as getting tokens for additional web API resources that may be called by the application. Se l'utente viene autenticato correttamente con Azure AD, per tale utente viene stabilita una sessione protetta da un cookie tra il browser e Azure AD.When the user successfully authenticates with Azure AD, a session secured by a cookie is established for the user between the browser and Azure AD. Tenere presente che la sessione esiste tra l'utente e Azure AD e non tra l'utente e l'applicazione Web in esecuzione sul server.It’s important to note that the session exists between the user and Azure AD and not between the user and the web application running on the server. Quando un token scade, ADAL.js usa questa sessione per ottenere automaticamente un altro token.When a token expires, ADAL.js uses this session to silently obtain another token. Ciò avviene usando un iFrame nascosto per inviare e ricevere la richiesta tramite il protocollo di concessione implicita OAuth.It does this by using a hidden iFrame to send and receive the request using the OAuth Implicit Grant protocol. ADAL.js può anche usare lo stesso meccanismo per ottenere automaticamente i token di accesso da Azure AD per altre risorse API Web chiamate dall'applicazione, purché queste risorse supportino la condivisione di risorse tra le origini (CORS), siano registrate nella directory dell'utente e sia stato assegnato dall'utente qualsiasi consenso richiesto durante l'accesso.ADAL.js can also use this same mechanism to silently obtain access tokens from Azure AD for other web API resources that the application calls as long as these resources support cross-origin resource sharing (CORS), are registered in the user’s directory, and any required consent was given by the user during sign-in.

Da applicazione nativa ad API WebNative Application to Web API

Questa sezione descrive un'applicazione nativa che chiama un'API Web per conto di un utente.This section describes a native application that calls a web API on behalf of a user. Questo scenario è basato sul tipo di concessione del codice di autorizzazione OAuth 2.0 con un client pubblico, come descritto nella sezione 4.1 della specifica OAuth 2.0.This scenario is built on the OAuth 2.0 authorization code grant type with a public client, as described in section 4.1 of the OAuth 2.0 specification. L'applicazione nativa ottiene un token di accesso per l'utente tramite il protocollo OAuth 2.0.The native application obtains an access token for the user by using the OAuth 2.0 protocol. Questo token di accesso viene quindi inviato nella richiesta all'API Web, che autorizza l'utente e restituisce la risorsa desiderata.This access token is then sent in the request to the web API, which authorizes the user and returns the desired resource.

DiagrammaDiagram

Diagramma Da applicazione nativa ad API Web

Flusso di autenticazione all'API per l'applicazione nativaAuthentication flow for native application to API

Descrizione del flusso del protocolloDescription of Protocol Flow

Se si usano le librerie di autenticazione AD, la maggior parte dei dettagli del protocollo descritti di seguito viene gestita automaticamente, ad esempio i popup del browser, la memorizzazione dei token nella cache e la gestione dei token di aggiornamento.If you are using the AD Authentication Libraries, most of the protocol details described below are handled for you, such as the browser pop-up, token caching, and handling of refresh tokens.

  1. Con un popup del browser l'applicazione nativa invia una richiesta all'endpoint di autorizzazione in Azure AD.Using a browser pop-up, the native application makes a request to the authorization endpoint in Azure AD. Questa richiesta include l'ID applicazione e l'URI di reindirizzamento dell'applicazione nativa, come illustrato nel Portale di Azure, nonché l'URI ID dell'applicazione per l'API Web.This request includes the Application ID and the redirect URI of the native application as shown in the Azure Portal, and the application ID URI for the web API. Se l'utente non ha ancora eseguito l'accesso, verrà richiesto di accedere di nuovo.If the user hasn’t already signed in, they are prompted to sign in again
  2. Azure AD autentica l'utente.Azure AD authenticates the user. Se si tratta di un'applicazione multi-tenant il cui uso richiede il consenso, verrà chiesto all'utente di fornire il consenso, se non l'ha già fatto.If it is a multi-tenant application and consent is required to use the application, the user will be required to consent if they haven’t already done so. Dopo che è stato fornito il consenso e l'autenticazione riesce, Azure AD restituisce un codice di autenticazione all'URI di reindirizzamento dell'applicazione client.After granting consent and upon successful authentication, Azure AD issues an authorization code response back to the client application’s redirect URI.
  3. Quando Azure AD restituisce un codice di autorizzazione all'URI di reindirizzamento, l'applicazione interrompe l'interazione con il browser ed estrae il codice di autorizzazione dalla risposta.When Azure AD issues an authorization code response back to the redirect URI, the client application stops browser interaction and extracts the authorization code from the response. Con questo codice di autorizzazione l'applicazione client invia una richiesta all'endpoint token di Azure AD che include il codice di autorizzazione, dettagli sull'applicazione client (ID applicazione e URI di reindirizzamento) e la risorsa desiderata (URI ID applicazione per l'API Web).Using this authorization code, the client application sends a request to Azure AD’s token endpoint that includes the authorization code, details about the client application (Application ID and redirect URI), and the desired resource (application ID URI for the web API).
  4. Il codice di autorizzazione e le informazioni sull'applicazione client e l'API Web vengono convalidati da Azure AD.The authorization code and information about the client application and web API are validated by Azure AD. Se la convalida riesce, Azure AD restituisce tue token: un token di accesso JWT e un token di aggiornamento JWT.Upon successful validation, Azure AD returns two tokens: a JWT access token and a JWT refresh token. Azure AD restituisce anche informazioni di base sull'utente, ad esempio il nome visualizzato e l'ID tenant.In addition, Azure AD returns basic information about the user, such as their display name and tenant ID.
  5. Su HTTPS l'applicazione client usa il token di accesso JWT restituito per aggiungere la stringa JWT con una designazione "Bearer" nell'intestazione dell'autorizzazione della richiesta all'API Web.Over HTTPS, the client application uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. L'API Web convalida quindi il token JWT e, se la convalida riesce, restituisce la risorsa desiderata.The web API then validates the JWT token, and if validation is successful, returns the desired resource.
  6. Alla scadenza del token di accesso l'applicazione client riceverà un errore che indica che l'utente deve ripetere il processo di autenticazione.When the access token expires, the client application will receive an error that indicates the user needs to authenticate again. Se l'applicazione ha un token di aggiornamento valido, può essere usato per acquisire un nuovo token di accesso senza richiedere all'utente di ripetere l'accesso.If the application has a valid refresh token, it can be used to acquire a new access token without prompting the user to sign in again. Se il token di aggiornamento scade, l'applicazione dovrà autenticare di nuovo l'utente in modo interattivo.If the refresh token expires, the application will need to interactively authenticate the user once again.

Nota

Il token di aggiornamento emesso da Azure AD può essere usato per accedere a più risorse.The refresh token issued by Azure AD can be used to access multiple resources. Ad esempio, se un'applicazione client è autorizzata a chiamare due API Web, il token di aggiornamento può essere usato per ottenere un token di accesso anche all'altra API Web.For example, if you have a client application that has permission to call two web APIs, the refresh token can be used to get an access token to the other web API as well.

Esempi di codiceCode Samples

Vedere gli esempi di codice per gli scenari Da applicazione nativa ad API Web.See the code samples for Native Application to Web API scenarios. Consultare spesso questa pagina perché vengono aggiunti regolarmente nuovi esempi.And, check back frequently -- we add new samples all the time. Da applicazione nativa ad API Web.Native Application to Web API.

RegistrazioneRegistering

  • Singolo tenant: l'applicazione nativa e l'API Web devono essere registrate nella stessa directory in Azure AD.Single Tenant: Both the native application and the web API must be registered in the same directory in Azure AD. L'API Web può essere configurata per esporre un set di autorizzazioni, che vengono usate per limitare l'accesso dell'applicazione nativa alle relative risorse.The web API can be configured to expose a set of permissions, which are used to limit the native application’s access to its resources. L'applicazione client seleziona quindi le autorizzazioni desiderate dal menu a discesa "Autorizzazioni per altre applicazioni" nel Portale di Azure.The client application then selects the desired permissions from the “Permissions to Other Applications” drop-down menu in the Azure Portal.
  • Multi-tenant: prima di tutto, l'applicazione nativa è stata registrata solo nella directory dello sviluppatore o dell'editore.Multi-Tenant: First, the native application only ever registered in the developer or publisher’s directory. Quindi, l'applicazione nativa viene configurata per indicare le autorizzazioni necessarie per il funzionamento.Second, the native application is configured to indicate the permissions it requires to be functional. Questo elenco di autorizzazioni richieste viene visualizzato in una finestra di dialogo quando un utente o amministratore nella directory di destinazione concede il consenso all'applicazione, rendendola disponibile per la propria organizzazione.This list of required permissions is shown in a dialog when a user or administrator in the destination directory gives consent to the application, which makes it available to their organization. Alcune applicazioni richiedono solo autorizzazioni a livello utente, che possono essere concesse da qualsiasi utente dell'organizzazione.Some applications require just user-level permissions, which any user in the organization can consent to. Altre applicazioni richiedono autorizzazioni a livello amministratore, che non possono essere concesse dagli utenti dell'organizzazione.Other applications require administrator-level permissions, which a user in the organization cannot consent to. Solo un amministratore di directory può concedere il consenso alle applicazioni che richiedono questo livello di autorizzazione.Only a directory administrator can give consent to applications that require this level of permissions. Quando l'utente o l'amministratore acconsente, solo l'API Web viene registrata nella directory.When the user or administrator consents, only the web API is registered in their directory. Per ulteriori informazioni, vedere Integrazione di applicazioni con Azure Active Directory.For more information, see Integrating Applications with Azure Active Directory.

Scadenza del tokenToken Expiration

Quando l'applicazione nativa usa il proprio codice di autorizzazione per ottenere un token di accesso JWT, riceve anche un token di aggiornamento JWT.When the native application uses its authorization code to get a JWT access token, it also receives a JWT refresh token. Quando il token di accesso scade, è possibile usare il token di aggiornamento per autenticare di nuovo l'utente senza richiedere di ripetere l'accesso.When the access token expires, the refresh token can be used to re-authenticate the user without requiring them to sign in again. Questo token di aggiornamento viene quindi usato per autenticare l'utente, con conseguente emissione di un nuovo token di accesso e un nuovo token di aggiornamento.This refresh token is then used to authenticate the user, which results in a new access token and refresh token.

Da applicazione Web ad API WebWeb Application to Web API

Questa sezione descrive un'applicazione Web che deve ottenere risorse da un'API Web.This section describes a web application that needs to get resources from a web API. In questo scenario esistono due tipi di identità che l'applicazione Web può usare per autenticare e chiamare l'API Web: un'identità applicazione e un'identità utente delegato.In this scenario, there are two identity types that the web application can use to authenticate and call the web API: an application identity, or a delegated user identity.

Identità applicazione: questo scenario usa la concessione di credenziali client OAuth 2.0 per l'autenticazione come applicazione e l'accesso all'API Web.Application identity: This scenario uses OAuth 2.0 client credentials grant to authenticate as the application and access the web API. Quando si usa un'identità applicazione, l'API Web può solo rilevare la chiamata dell'applicazione Web, perché non riceve informazioni relative all'utente.When using an application identity, the web API can only detect that the web application is calling it, as the web API does not receive any information about the user. Se l'applicazione riceve informazioni relative all'utente, queste vengono inviate tramite il protocollo applicativo e non sono firmate da Azure AD.If the application receives information about the user, it will be sent via the application protocol, and it is not signed by Azure AD. L'API Web confida che l'applicazione Web abbia autenticato l'utente.The web API trusts that the web application authenticated the user. Per questo motivo il modello è definito sottosistema attendibile.For this reason, this pattern is called a trusted subsystem.

Identità utente delegato: lo scenario può essere eseguito in due modi, ovvero OpenID Connect e concessione di codice di autorizzazione OAuth 2.0 con un client riservato.Delegated user identity: This scenario can be accomplished in two ways: OpenID Connect, and OAuth 2.0 authorization code grant with a confidential client. L'applicazione Web ottiene un token di accesso per l'utente, dimostrando all'API Web che l'utente è stato autenticato nell'applicazione Web e che l'applicazione Web è riuscita a ottenere un'identità utente delegato per chiamare l'API Web.The web application obtains an access token for the user, which proves to the web API that the user successfully authenticated to the web application and that the web application was able to obtain a delegated user identity to call the web API. Questo token di accesso viene inviato nella richiesta all'API Web, che autorizza l'utente e restituisce la risorsa desiderata.This access token is sent in the request to the web API, which authorizes the user and returns the desired resource.

DiagrammaDiagram

Diagramma Da applicazione Web ad API Web

Descrizione del flusso del protocolloDescription of Protocol Flow

Nel flusso che segue sono illustrati i tipi di identità applicazione e identità utente delegato.Both the application identity and delegated user identity types are discussed in the flow below. La differenza fondamentale consiste nel fatto che l'identità utente delegato deve acquisire un codice di autorizzazione prima che l'utente possa ottenere l'accesso all'API Web.The key difference between them is that the delegated user identity must first acquire an authorization code before the user can sign-in and gain access to the web API.

Identità applicazione con concessione delle credenziali client OAuth 2.0Application Identity with OAuth 2.0 Client Credentials Grant
  1. Un utente esegue l'accesso ad Azure AD nell'applicazione Web (vedere la sezione precedente Da Web browser ad applicazione Web ).A user is signed in to Azure AD in the web application (see the Web Browser to Web Application above).
  2. L'applicazione Web deve acquisire un token di accesso per l'autenticazione nell'API Web e il recupero della risorsa desiderata.The web application needs to acquire an access token so that it can authenticate to the web API and retrieve the desired resource. Esegue una richiesta all'endpoint token di Azure AD, fornendo credenziali, ID applicazione e URI ID applicazione dell'API Web.It makes a request to Azure AD’s token endpoint, providing the credential, Application ID, and web API’s application ID URI.
  3. Azure AD autentica l'applicazione e restituisce un token di accesso JWT usato per chiamare l'API Web.Azure AD authenticates the application and returns a JWT access token that is used to call the web API.
  4. Su HTTPS l'applicazione Web usa il token di accesso JWT restituito per aggiungere la stringa JWT con una designazione "Bearer" nell'intestazione dell'autorizzazione della richiesta all'API Web.Over HTTPS, the web application uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. L'API Web convalida quindi il token JWT e, se la convalida riesce, restituisce la risorsa desiderata.The web API then validates the JWT token, and if validation is successful, returns the desired resource.
Identità utente delegato con OpenID ConnectDelegated User Identity with OpenID Connect
  1. Un utente esegue l'accesso all'applicazione Web usando Azure AD (vedere la sezione precedente Da Web browser ad applicazione Web ).A user is signed in to a web application using Azure AD (see the Web Browser to Web Application section above). Se l'utente dell'applicazione Web non ha ancora concesso il consenso perché l'applicazione Web chiami l'API Web per suo conto, dovrà acconsentire.If the user of the web application has not yet consented to allowing the web application to call the web API on its behalf, the user will need to consent. L'applicazione visualizzerà le autorizzazioni richieste e, se si tratta di autorizzazione a livello amministratore, un utente normale della directory non potrà concedere il consenso.The application will display the permissions it requires, and if any of these are administrator-level permissions, a normal user in the directory will not be able to consent. Questo processo di consenso è valido solo per le applicazioni multi-tenant, non per le applicazioni con un singolo tenant, perché l'applicazione avrà già le autorizzazioni necessarie.This consent process only applies to multi-tenant applications, not single tenant applications, as the application will already have the necessary permissions. Quando l'utente ha eseguito l'accesso, l'applicazione Web ha ricevuto un token ID con le informazioni relative all'utente, nonché un codice di autorizzazione.When the user signed in, the web application received an ID token with information about the user, as well as an authorization code.
  2. Con il codice di autorizzazione rilasciato da Azure AD, l'applicazione Web invia una richiesta all'endpoint token di Azure AD che include il codice di autorizzazione, dettagli sull'applicazione client (ID applicazione e URI di reindirizzamento) e la risorsa desiderata (URI ID applicazione per l'API Web).Using the authorization code issued by Azure AD, the web application sends a request to Azure AD’s token endpoint that includes the authorization code, details about the client application (Application ID and redirect URI), and the desired resource (application ID URI for the web API).
  3. Il codice di autorizzazione e le informazioni sull'applicazione Web e l'API Web vengono convalidati da Azure AD.The authorization code and information about the web application and web API are validated by Azure AD. Se la convalida riesce, Azure AD restituisce tue token: un token di accesso JWT e un token di aggiornamento JWT.Upon successful validation, Azure AD returns two tokens: a JWT access token and a JWT refresh token.
  4. Su HTTPS l'applicazione Web usa il token di accesso JWT restituito per aggiungere la stringa JWT con una designazione "Bearer" nell'intestazione dell'autorizzazione della richiesta all'API Web.Over HTTPS, the web application uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. L'API Web convalida quindi il token JWT e, se la convalida riesce, restituisce la risorsa desiderata.The web API then validates the JWT token, and if validation is successful, returns the desired resource.
Identità utente delegato con concessione del codice di autorizzazione OAuth 2.0Delegated User Identity with OAuth 2.0 Authorization Code Grant
  1. Un utente ha già eseguito l'accesso all'applicazione Web, il cui meccanismo di autenticazione è indipendente da Azure AD.A user is already signed in to a web application, whose authentication mechanism is independent of Azure AD.
  2. L'applicazione Web richiede un codice di autorizzazione per acquisire un token di accesso, quindi invia una richiesta tramite il browser all'endpoint di autorizzazione di Azure AD, fornendo l'ID applicazione e l'URI di reindirizzamento per l'applicazione Web al termine dell'autenticazione.The web application requires an authorization code to acquire an access token, so it issues a request through the browser to Azure AD’s authorization endpoint, providing the Application ID and redirect URI for the web application after successful authentication. L'utente accede ad Azure AD.The user signs in to Azure AD.
  3. Se l'utente dell'applicazione Web non ha ancora concesso il consenso perché l'applicazione Web chiami l'API Web per suo conto, dovrà acconsentire.If the user of the web application has not yet consented to allowing the web application to call the web API on its behalf, the user will need to consent. L'applicazione visualizzerà le autorizzazioni richieste e, se si tratta di autorizzazione a livello amministratore, un utente normale della directory non potrà concedere il consenso.The application will display the permissions it requires, and if any of these are administrator-level permissions, a normal user in the directory will not be able to consent. Il consenso si applica sia all'applicazione a tenant singolo che multi-tenant.This consent applies to both single and multi-tenant application. In un'applicazione a tenant singolo l'amministratore può eseguire il consenso dell'amministratore per acconsentire per conto degli utenti.In the single tenant case, an admin can perform admin consent to consent on behalf of their users. Per questa operazione è possibile usare il pulsante Grant Permissions nel portale di Azure.This can be done using the Grant Permissions button in the Azure Portal.
  4. Quando l'utente concede il consenso, l'applicazione Web riceve il codice di autorizzazione necessario per acquisire un token di accesso.After the user has consented, the web application receives the authorization code that it needs to acquire an access token.
  5. Con il codice di autorizzazione rilasciato da Azure AD, l'applicazione Web invia una richiesta all'endpoint token di Azure AD che include il codice di autorizzazione, dettagli sull'applicazione client (ID applicazione e URI di reindirizzamento) e la risorsa desiderata (URI ID applicazione per l'API Web).Using the authorization code issued by Azure AD, the web application sends a request to Azure AD’s token endpoint that includes the authorization code, details about the client application (Application ID and redirect URI), and the desired resource (application ID URI for the web API).
  6. Il codice di autorizzazione e le informazioni sull'applicazione Web e l'API Web vengono convalidati da Azure AD.The authorization code and information about the web application and web API are validated by Azure AD. Se la convalida riesce, Azure AD restituisce tue token: un token di accesso JWT e un token di aggiornamento JWT.Upon successful validation, Azure AD returns two tokens: a JWT access token and a JWT refresh token.
  7. Su HTTPS l'applicazione Web usa il token di accesso JWT restituito per aggiungere la stringa JWT con una designazione "Bearer" nell'intestazione dell'autorizzazione della richiesta all'API Web.Over HTTPS, the web application uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. L'API Web convalida quindi il token JWT e, se la convalida riesce, restituisce la risorsa desiderata.The web API then validates the JWT token, and if validation is successful, returns the desired resource.

Esempi di codiceCode Samples

Vedere gli esempi di codice per gli scenari Da applicazione Web ad API Web.See the code samples for Web Application to Web API scenarios. Consultare spesso questa pagina perché vengono aggiunti regolarmente nuovi esempi.And, check back frequently -- we add new samples all the time. Da applicazione Web ad API Web.Web Application to Web API.

RegistrazioneRegistering

  • Singolo tenant: in entrambi i casi (identità applicazione e identità utente delegato), l'applicazione Web e l'API Web devono essere registrate nella stessa directory in Azure AD.Single Tenant: For both the application identity and delegated user identity cases, the web application and the web API must be registered in the same directory in Azure AD. L'API Web può essere configurata per esporre un set di autorizzazioni, che vengono usate per limitare l'accesso dell'applicazione Web alle relative risorse.The web API can be configured to expose a set of permissions, which are used to limit the web application’s access to its resources. Se viene usato il tipo di identità utente delegato, l'applicazione Web deve selezionare le autorizzazioni desiderate dal menu a discesa "Autorizzazioni per altre applicazioni" nel Portale di Azure.If a delegated user identity type is being used, the web application needs to select the desired permissions from the “Permissions to Other Applications” drop-down menu in the Azure Portal. Questo passaggio non è necessario se viene usato il tipo di identità applicazione.This step is not required if the application identity type is being used.
  • Multi-tenant: per prima cosa, l'applicazione Web viene configurata per indicare le autorizzazioni necessarie per il funzionamento.Multi-Tenant: First, the web application is configured to indicate the permissions it requires to be functional. Questo elenco di autorizzazioni richieste viene visualizzato in una finestra di dialogo quando un utente o amministratore nella directory di destinazione concede il consenso all'applicazione, rendendola disponibile per la propria organizzazione.This list of required permissions is shown in a dialog when a user or administrator in the destination directory gives consent to the application, which makes it available to their organization. Alcune applicazioni richiedono solo autorizzazioni a livello utente, che possono essere concesse da qualsiasi utente dell'organizzazione.Some applications require just user-level permissions, which any user in the organization can consent to. Altre applicazioni richiedono autorizzazioni a livello amministratore, che non possono essere concesse dagli utenti dell'organizzazione.Other applications require administrator-level permissions, which a user in the organization cannot consent to. Solo un amministratore di directory può concedere il consenso alle applicazioni che richiedono questo livello di autorizzazione.Only a directory administrator can give consent to applications that require this level of permissions. Quando l'utente o l'amministratore acconsente, l'applicazione Web e l'API Web vengono registrate nella directory.When the user or administrator consents, the web application and the web API are both registered in their directory.

Scadenza del tokenToken Expiration

Quando l'applicazione Web usa il proprio codice di autorizzazione per ottenere un token di accesso JWT, riceve anche un token di aggiornamento JWT.When the web application uses its authorization code to get a JWT access token, it also receives a JWT refresh token. Quando il token di accesso scade, è possibile usare il token di aggiornamento per autenticare di nuovo l'utente senza richiedere di ripetere l'accesso.When the access token expires, the refresh token can be used to re-authenticate the user without requiring them to sign in again. Questo token di aggiornamento viene quindi usato per autenticare l'utente, con conseguente emissione di un nuovo token di accesso e un nuovo token di aggiornamento.This refresh token is then used to authenticate the user, which results in a new access token and refresh token.

Da daemon o applicazione server ad API WebDaemon or Server Application to Web API

Questa sezione descrive un'applicazione daemon o server che deve ottenere risorse da un'API Web.This section describes a daemon or server application that needs to get resources from a web API. A questa sezione sono applicabili due sottoscenari: un'applicazione daemon che deve chiamare un'API Web, basata sul tipo di concessione di credenziali client OAuth 2.0, e un'applicazione server (ad esempio un'API Web) che deve chiamare un'API Web, basata sulla bozza di specifica OAuth 2.0 On-Behalf-Of.There are two sub-scenarios that apply to this section: A daemon that needs to call a web API, built on OAuth 2.0 client credentials grant type; and a server application (such as a web API) that needs to call a web API, built on OAuth 2.0 On-Behalf-Of draft specification.

Per lo scenario in cui un'applicazione daemon deve chiamare un'API Web, è importante comprendere alcuni aspetti.For the scenario when a daemon application needs to call a web API, it’s important to understand a few things. Prima di tutto, l'interazione utente non è possibile con un'applicazione daemon, che richiede che l'applicazione abbia una propria identità.First, user interaction is not possible with a daemon application, which requires the application to have its own identity. Un esempio di applicazione daemon è un processo batch oppure un servizio del sistema operativo in esecuzione in background.An example of a daemon application is a batch job, or an operating system service running in the background. Questo tipo di applicazione richiede un token di accesso usando la relativa identità applicazione e presentando l'ID applicazione, le credenziali (password o certificato) e l'URI ID dell'applicazione ad Azure AD.This type of application requests an access token by using its application identity and presenting its Application ID, credential (password or certificate), and application ID URI to Azure AD. Dopo l'autenticazione, il daemon riceve un token di accesso da Azure AD, che viene quindi usato per chiamare l'API Web.After successful authentication, the daemon receives an access token from Azure AD, which is then used to call the web API.

Per lo scenario in cui un'applicazione server deve chiamare un'API Web, è utile usare un esempio.For the scenario when a server application needs to call a web API, it’s helpful to use an example. Si supponga che un utente abbia eseguito l'autenticazione in un'applicazione nativa e che questa abbia l'esigenza di chiamare un'API Web.Imagine that a user has authenticated on a native application, and this native application needs to call a web API. Azure AD rilascia un token di accesso JWT per chiamare l'API Web.Azure AD issues a JWT access token to call the web API. Se l'API Web deve chiamare un'altra API Web a valle, può usare il flusso "on-behalf-of" per delegare l'identità dell'utente ed eseguire l'autenticazione nell'API Web di secondo livello.If the web API needs to call another downstream web API, it can use the on-behalf-of flow to delegate the user’s identity and authenticate to the second-tier web API.

DiagrammaDiagram

Diagramma Da daemon o applicazione server ad API Web

Descrizione del flusso del protocolloDescription of Protocol Flow

Identità applicazione con concessione delle credenziali client OAuth 2.0Application Identity with OAuth 2.0 Client Credentials Grant
  1. Per prima cosa, l'applicazione server deve eseguire l'autenticazione in Azure AD senza intervento dell'utente, ad esempio senza finestra di dialogo di accesso interattiva.First, the server application needs to authenticate with Azure AD as itself, without any human interaction such as an interactive sign-on dialog. Esegue una richiesta all'endpoint token di Azure AD, fornendo credenziali, ID applicazione e URI ID applicazione.It makes a request to Azure AD’s token endpoint, providing the credential, Application ID, and application ID URI.
  2. Azure AD autentica l'applicazione e restituisce un token di accesso JWT usato per chiamare l'API Web.Azure AD authenticates the application and returns a JWT access token that is used to call the web API.
  3. Su HTTPS l'applicazione Web usa il token di accesso JWT restituito per aggiungere la stringa JWT con una designazione "Bearer" nell'intestazione dell'autorizzazione della richiesta all'API Web.Over HTTPS, the web application uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. L'API Web convalida quindi il token JWT e, se la convalida riesce, restituisce la risorsa desiderata.The web API then validates the JWT token, and if validation is successful, returns the desired resource.
Identità utente delegato con la bozza di specifica OAuth 2.0 On-Behalf-OfDelegated User Identity with OAuth 2.0 On-Behalf-Of Draft Specification

Il flusso descritto di seguito presuppone che un utente abbia eseguito l'autenticazione in un'altra applicazione (ad esempio un'applicazione nativa) e che la relativa identità utente sia stata usata per acquisire un token di accesso all'API Web di primo livello.The flow discussed below assumes that a user has been authenticated on another application (such as a native application), and their user identity has been used to acquire an access token to the first-tier web API.

  1. L'applicazione nativa invia il token di accesso all'API Web di primo livello.The native application sends the access token to the first-tier web API.
  2. L'API Web di primo livello invia una richiesta all'endpoint token di Azure AD, inviando l'ID applicazione e le credenziali, oltre al token di accesso dell'utente.The first-tier web API sends a request to Azure AD’s token endpoint, providing its Application ID and credentials, as well as the user’s access token. Inoltre, la richiesta viene inviata con un parametro on_behalf_of che indica che l'API Web richiede nuovi token per chiamare un'API Web a valle per conto dell'utente originale.In addition, the request is sent with an on_behalf_of parameter that indicates the web API is requesting new tokens to call a downstream web API on behalf of the original user.
  3. Azure AD verifica che l'API Web di primo livello sia autorizzata ad accedere all'API Web di secondo livello e convalidi la richiesta, restituendo un token di accesso JWT e un token di aggiornamento JWT all'API Web di primo livello.Azure AD verifies that the first-tier web API has permissions to access the second-tier web API and validates the request, returning a JWT access token and a JWT refresh token to the first-tier web API.
  4. Su HTTPS, l'API Web di primo livello chiama l'API Web di secondo livello aggiungendo la stringa del token all'intestazione dell'autorizzazione nella richiesta.Over HTTPS, the first-tier web API then calls the second-tier web API by appending the token string in the Authorization header in the request. L'API Web di primo livello può continuare a chiamare l'API Web di secondo livello finché il token di accesso e i token di aggiornamento sono validi.The first-tier web API can continue to call the second-tier web API as long as the access token and refresh tokens are valid.

Esempi di codiceCode Samples

Vedere gli esempi di codice per gli scenari Da applicazione daemon o server ad API Web.See the code samples for Daemon or Server Application to Web API scenarios. Consultare spesso questa pagina perché vengono aggiunti regolarmente nuovi esempi.And, check back frequently -- we add new samples all the time. Applicazione server o daemon ad API WebServer or Daemon Application to Web API

RegistrazioneRegistering

  • Singolo tenant: in entrambi i casi (identità applicazione e identità utente delegato), l'applicazione daemon o server deve essere registrata nella stessa directory in Azure AD.Single Tenant: For both the application identity and delegated user identity cases, the daemon or server application must be registered in the same directory in Azure AD. L'API Web può essere configurata per esporre un set di autorizzazioni, che vengono usate per limitare l'accesso del daemon o del server alle relative risorse.The web API can be configured to expose a set of permissions, which are used to limit the daemon or server’s access to its resources. Se viene usato il tipo di identità utente delegato, l'applicazione server deve selezionare le autorizzazioni desiderate dal menu a discesa "Autorizzazioni per altre applicazioni" nel Portale di Azure.If a delegated user identity type is being used, the server application needs to select the desired permissions from the “Permissions to Other Applications” drop-down menu in the Azure Portal. Questo passaggio non è necessario se viene usato il tipo di identità applicazione.This step is not required if the application identity type is being used.
  • Multi-tenant: per prima cosa, l'applicazione daemon o server viene configurata per indicare le autorizzazioni necessarie per il funzionamento.Multi-Tenant: First, the daemon or server application is configured to indicate the permissions it requires to be functional. Questo elenco di autorizzazioni richieste viene visualizzato in una finestra di dialogo quando un utente o amministratore nella directory di destinazione concede il consenso all'applicazione, rendendola disponibile per la propria organizzazione.This list of required permissions is shown in a dialog when a user or administrator in the destination directory gives consent to the application, which makes it available to their organization. Alcune applicazioni richiedono solo autorizzazioni a livello utente, che possono essere concesse da qualsiasi utente dell'organizzazione.Some applications require just user-level permissions, which any user in the organization can consent to. Altre applicazioni richiedono autorizzazioni a livello amministratore, che non possono essere concesse dagli utenti dell'organizzazione.Other applications require administrator-level permissions, which a user in the organization cannot consent to. Solo un amministratore di directory può concedere il consenso alle applicazioni che richiedono questo livello di autorizzazione.Only a directory administrator can give consent to applications that require this level of permissions. Quando l'utente o l'amministratore acconsente, entrambe le API Web vengono registrate nella directory.When the user or administrator consents, both of the web APIs are registered in their directory.

Scadenza del tokenToken Expiration

Quando la prima applicazione usa il proprio codice di autorizzazione per ottenere un token di accesso JWT, riceve anche un token di aggiornamento JWT.When the first application uses its authorization code to get a JWT access token, it also receives a JWT refresh token. Quando il token di accesso scade, è possibile usare il token di aggiornamento per autenticare di nuovo l'utente senza richiedere l'immissione delle credenziali.When the access token expires, the refresh token can be used to re-authenticate the user without prompting for credentials. Questo token di aggiornamento viene quindi usato per autenticare l'utente, con conseguente emissione di un nuovo token di accesso e un nuovo token di aggiornamento.This refresh token is then used to authenticate the user, which results in a new access token and refresh token.

Vedere ancheSee Also

Guida per gli sviluppatori di Azure Active DirectoryAzure Active Directory Developer's Guide

Esempi di codice di Azure Active DirectoryAzure Active Directory Code Samples

Informazioni importanti sul rollover della chiave di firma in Azure ADImportant Information About Signing Key Rollover in Azure AD

OAuth 2.0 in Azure ADOAuth 2.0 in Azure AD