Glossario per gli sviluppatori di Azure Active Directory

Questo articolo contiene le definizioni di alcuni dei concetti di base per gli sviluppatori di Azure Active Directory (AD), utili per imparare a sviluppare applicazioni per Azure AD.

token di accesso

Tipo di token di sicurezza rilasciato da un server di autorizzazione e usato da un'applicazione client per accedere a un server di risorse protette. Il token, in genere sotto forma di token JSON Web (token JWT), rappresenta l'autorizzazione concessa dal proprietario delle risorse al client per un livello di accesso richiesto. Il token contiene tutte le attestazioni applicabili relative al soggetto e può essere usato dall'applicazione client come credenziale per accedere a una determinata risorsa. Il proprietario della risorsa non dovrà quindi esporre le credenziali al client.

I token di accesso sono talvolta definiti "utente + app" o "solo app", a seconda delle credenziali rappresentate. Ad esempio:

  • Quando un'applicazione client usa la concessione di autorizzazione "codice di autorizzazione", l'utente finale esegue prima l'autenticazione come proprietario della risorsa, delegando al client l'autorizzazione ad accedere alla risorsa. Il client esegue successivamente l'autenticazione quando ottiene il token di accesso. Il token può talvolta essere definito più specificamente token "utente + app" perché rappresenta sia l'utente che ha autorizzato l'applicazione client che l'applicazione.
  • Quando un'applicazione client usa la concessione di autorizzazione "credenziali client", il client fornisce la sola autenticazione e funziona senza l'autenticazione/autorizzazione del proprietario della risorsa. Il token può quindi essere definito talvolta token "solo app".

Per altri dettagli, vedere Informazioni di riferimento sui token in Azure AD.

manifesto dell'applicazione

Funzionalità offerta dal portale di Azure che genera una rappresentazione JSON della configurazione di identità dell'applicazione e viene usata come meccanismo per aggiornare le entità Application e ServicePrincipal associate. Per altri dettagli, vedere Informazioni sul manifesto dell'applicazione in Azure Active Directory.

oggetto applicazione

Quando si registra/aggiorna un'applicazione nel portale di Azure, il portale crea/aggiorna sia un oggetto applicazione che un oggetto entità servizio corrispondente per il tenant. L'oggetto applicazione definisce la configurazione di identità dell'applicazione a livello globale (in tutti i tenant a cui ha accesso), offrendo un modello da cui derivano gli oggetti entità servizio corrispondenti usati in locale in fase di esecuzione (in uno specifico tenant).

Per altre informazioni, vedere Oggetti applicazione e oggetti entità servizio in Azure Active Directory.

registrazione dell'applicazione

Per consentire a un'applicazione l'integrazione con le funzioni di gestione delle identità e degli accessi e la relativa delega in Azure AD, è necessario che l'applicazione sia registrata in un tenantdi Azure AD. Quando si registra l'applicazione in Azure AD, si specifica una configurazione di identità per l'applicazione che ne consente l'integrazione con Azure AD e l'uso di funzionalità come le seguenti:

Per altri dettagli, vedere Integrazione di applicazioni con Azure Active Directory.

authentication

Richiesta di credenziali legittime a una parte, che costituisce la base per la creazione di un'entità di sicurezza da usare per il controllo delle identità e di accesso. Durante una concessione di autorizzazione OAuth2, ad esempio, la parte che esegue l'autenticazione svolge il ruolo di proprietario delle risorse o di applicazione client a seconda della concessione usata.

autorizzazione

Concessione a un'entità di sicurezza autenticata dell'autorizzazione a eseguire determinate operazioni. Nel modello di programmazione di Azure AD esistono due casi d'uso principali.

codice di autorizzazione

"Token" di breve durata fornito a un'applicazione client dall'endpoint di autorizzazione nell'ambito del flusso del "codice di autorizzazione". È una delle quattro concessioni di autorizzazione OAuth2. Il codice viene restituito all'applicazione client in risposta all'autenticazione di un proprietario delle risorse e indica che il proprietario ha delegato l'autorizzazione ad accedere alle risorse richieste. Nell'ambito del flusso, il codice viene successivamente riscattato per un token di accesso.

endpoint di autorizzazione

Uno degli endpoint implementati dal server di autorizzazione, usato per interagire con il proprietario delle risorse per fornire una concessione di autorizzazione durante un flusso di concessione di autorizzazione OAuth2. A seconda del flusso di concessione di autorizzazione usato, l'effettiva concessione fornita può variare e includere un codice di autorizzazione o un token di sicurezza.

Per altri dettagli, vedere le sezioni relative ai tipi di concessione di autorizzazione e all'endpoint di autorizzazione della specifica OAuth2 e la specifica OpenIDConnect.

concessione di autorizzazione

Credenziale che rappresenta l'autorizzazione del proprietario delle risorse ad accedere alle risorse protette, concessa a un'applicazione client. Per ottenere una concessione, un'applicazione client può usare uno dei quattro tipi di concessione definiti dal framework di autorizzazione di OAuth2, a seconda del tipo e dei requisiti del client: concessione del codice di autorizzazione, concessione di credenziali client, concessione implicita e concessione delle credenziali password del proprietario della risorsa. A seconda del tipo di concessione di autorizzazione usato, la credenziale restituita al client è un token di accesso o un codice di autorizzazione successivamente scambiato con un token di accesso.

server di autorizzazione

In base alla definizione del framework di autorizzazione di OAuth2, server responsabile del rilascio dei token di accesso al client dopo che è stata completata l'autenticazione del proprietario delle risorse e ne è stata ottenuta l'autorizzazione. Un'applicazione client interagisce con il server di autorizzazione in fase di esecuzione tramite gli endpoint di autorizzazione e di token, in conformità alle concessioni di autorizzazione definite da OAuth2.

In caso di integrazione di applicazioni di Azure AD, Azure AD implementa il ruolo del server di autorizzazione per le applicazioni di Azure AD e le API del servizio Microsoft, ad esempio le API Microsoft Graph.

attestazione

Un token di sicurezza contiene attestazioni, che forniscono asserzioni su un'entità (come un'applicazione client o un proprietario delle risorse) a un'altra entità, ad esempio il server di risorse. Le attestazioni sono coppie nome-valore che inoltrano fact relativi al soggetto del token (ad esempio, l'identità di sicurezza che è stata autenticata dal server di autorizzazione). Le attestazioni presenti in un determinato token dipendono da diverse variabili, tra cui il tipo di token, il tipo di credenziale usato per autenticare il soggetto, la configurazione dell'applicazione e così via.

Per altri dettagli, vedere Informazioni di riferimento sui token in Azure AD.

applicazione client

In base alla definizione del framework di autorizzazione di OAuth2, applicazione che effettua richieste di risorse protette per conto del proprietario delle risorse. Il termine "client" non implica particolari caratteristiche di implementazione a livello di hardware, ad esempio l'esecuzione dell'applicazione su un server, un PC desktop o altri dispositivi.

Un'applicazione client richiede l'autorizzazione da un proprietario delle risorse a partecipare a un flusso di concessione di autorizzazione OAuth2 e può accedere alle API e ai dati per conto del proprietario delle risorse. Il framework di autorizzazione di OAuth2 definisce due tipi di client, "riservato" e "pubblico", in base alla possibilità di mantenere riservate le proprie credenziali. Le applicazioni possono implementare un client Web (riservato) eseguito in un server Web, un client nativo (pubblico) installato in un dispositivo o un client basato su agente utente (pubblico) eseguito nel browser di un dispositivo.

Processo secondo cui un proprietario di risorse concede l'autorizzazione a un'applicazione client per accedere a risorse protette con specifiche autorizzazioni per conto del proprietario delle risorse. A seconda delle autorizzazioni richieste dal client, verrà chiesto a un amministratore o a un utente di dare il consenso per permettere l'accesso, rispettivamente, ai dati dell'organizzazione o individuali. Si noti che in uno scenario multi-tenant, l'entità servizio dell'applicazione viene registrata anche nel tenant dell'utente che dà il consenso.

token ID

Token di sicurezza OpenID Connect fornito dall' endpoint di autorizzazione di un server di autorizzazione che contiene attestazioni relative all'autenticazione di un proprietario delle risorse utente finale. Così come i token di accesso, i token ID sono rappresentati anche come token JSON Web (token JWT) con firma digitale. A differenza di un token di accesso, tuttavia, le attestazioni di un token ID non vengono usate per scopi correlati all'accesso alle risorse e specificamente al controllo di accesso.

Per altri dettagli, vedere Informazioni di riferimento sui token in Azure AD.

applicazione multi-tenant

Classe di applicazione che consente l'accesso e il consenso da utenti di cui è stato eseguito il provisioning in un qualsiasi tenant di Azure AD, anche se diverso da quello in cui il client è registrato. Le applicazioni cliente native sono multi-tenant per impostazione predefinita, mentre le applicazioni client Web e API/risorse Web possono essere a tenant singolo o multi-tenant. Un'applicazione Web registrata come a tenant singolo, invece, consentirà accessi solo da account utente con provisioning nello stesso tenant in cui l'applicazione è stata registrata.

Per altri dettagli, vedere Come consentire l'accesso a qualsiasi utente di Azure Active Directory (AD) usando il modello di applicazione multi-tenant.

client nativo

Tipo di applicazione client che è installato in modo nativo in un dispositivo. Poiché tutto il codice viene eseguito in un dispositivo, il client viene considerato "pubblico" perché non può eseguire l'archiviazione privata/riservata delle credenziali. Per altri dettagli, vedere i profili e i tipi di client di OAuth2.

autorizzazioni

Un'applicazione client ottiene l'accesso a un server di risorse dichiarando richieste di autorizzazione. Sono disponibili due tipi:

Vengono presentate anche durante il processo di consenso per offrire all'amministratore o al proprietario delle risorse l'opportunità di concedere/negare l'accesso client alle risorse nel tenant.

Le richieste di autorizzazione vengono configurate nella scheda "Applicazioni"/"Impostazioni" del portale di Azure in "Autorizzazioni richieste", selezionando le "Autorizzazioni delegate" e le "Autorizzazioni applicazione" desiderate (per il secondo tipo è necessario essere membri del ruolo Global Admin). Dal momento che un client pubblico non può gestire le credenziali in modo sicuro, può solo richiedere autorizzazioni delegate, mentre un client riservato può richiedere autorizzazioni sia delegate che applicazione. Le autorizzazioni dichiarate vengono archiviate dall'oggetto applicazione del client nella proprietà requiredResourceAccess.

proprietario delle risorse

In base alla definizione del framework di autorizzazione di OAuth2, entità che può concedere l'accesso a una risorsa protetta. Quando il proprietario delle risorse è una persona, è definito utente finale. Quando un'applicazione client vuole accedere alla cassetta postale di un utente tramite l'API Microsoft Graph, ad esempio, richiede l'autorizzazione dal proprietario della risorsa della cassetta postale.

server di risorse

In base alla definizione del framework di autorizzazione di OAuth2, server che ospita risorse protette e può accettare e rispondere alle relative richieste effettuate da applicazioni client che presentano un token di accesso. È detto anche server di risorse protette o applicazione della risorsa.

Un server di risorse espone le API e consente l'accesso alle proprie risorse protette tramite ambiti e ruoli, usando il framework di autorizzazione di OAuth 2.0. Gli esempi includono l'API Graph di Azure AD che consente di accedere ai dati dei tenant di Azure AD e le API di Office 365 che consentono di accedere a dati come posta e calendario. Entrambi sono accessibili anche tramite l'API Graph di Microsoft.

Così come per un'applicazione client, la configurazione di identità dell'applicazione della risorsa viene definita tramite la registrazione in un tenant di Azure AD, con cui vengono specificati sia l'oggetto applicazione che l'oggetto entità servizio. Alcune API fornite da Microsoft, come l'API Graph di Azure AD, includono entità servizio preregistrate che vengono rese disponibili in tutti i tenant durante il provisioning.

roles

Così come gli ambiti, i ruoli consentono a un server di risorse di controllare l'accesso alle proprie risorse protette. Ne esistono due tipi: il ruolo "utente" implementa il controllo degli accessi in base al ruolo per gli utenti e i gruppi che devono accedere alla risorsa, mentre il ruolo "applicazione" esegue la stessa implementazione per le applicazioni client che devono accedere.

I ruoli sono stringhe definite a livello di risorsa, ad esempio "Expense approver", "Read-only", "Directory.ReadWrite.All", vengono gestiti nel portale di Azure tramite il manifesto dell'applicazione della risorsa e vengono archiviati nella proprietà appRoles della risorsa. Il portale di Azure viene usato anche per assegnare gli utenti ai ruoli utente e configurare le autorizzazioni applicazione client per l'accesso a un ruolo applicazione.

Per una descrizione dettagliata dei ruoli applicazione esposti dall'API Graph di Azure AD, vedere Ambiti di autorizzazione | Concetti relativi all'API Graph. Per un esempio dettagliato di implementazione, vedere Role based access control in cloud applications using Azure AD (Controllo degli accessi in base al ruolo nelle applicazioni cloud con Azure AD).

ambiti

Così come i ruoli, gli ambiti consentono a un server di risorse di controllare l'accesso alle proprie risorse protette. Gli ambiti vengono usati per implementare il controllo di accesso in base all'ambito per un'applicazione client che ha ottenuto l'accesso delegato alla risorsa dal relativo proprietario.

Gli ambiti sono stringhe definite a livello di risorsa, ad esempio "Mail.Read", "Directory.ReadWrite.All", vengono gestiti nel portale di Azure tramite il manifesto dell'applicazione della risorsa e vengono archiviati nella proprietà oauth2Permissions della risorsa. Il portale di Azure viene usato anche per configurare le autorizzazioni delegate dell'applicazione client per l'accesso a un ambito.

Come convenzione di denominazione, la procedura consigliata è usare il formato "risorsa.operazione.vincolo". Per una descrizione dettagliata degli ambiti esposti dall'API Graph di Azure AD, vedere Ambiti di autorizzazione | Concetti relativi all'API Graph. Per informazioni sugli ambiti esposti dai servizi di Office 365, vedere Office 365 API permissions reference (Informazioni di riferimento sulle autorizzazioni delle API di Office 365).

token di sicurezza

Documento firmato contenente attestazioni, come un token OAuth2 o un'asserzione SAML 2.0. Per una concessione di autorizzazione OAuth2, un token di accesso (OAuth2) e un token ID costituiscono un tipo di token di sicurezza e vengono entrambi implementati come token JSON Web (token JWT).

oggetto entità servizio

Quando si registra/aggiorna un'applicazione nel portale di Azure, il portale crea/aggiorna sia un oggetto applicazione che un oggetto entità servizio corrispondente per il tenant. L'oggetto applicazione definisce la configurazione di identità dell'applicazione a livello globale, ovvero in tutti i tenant in cui all'applicazione associata è stato concesso l'accesso, ed è il modello da cui derivano gli oggetti entità servizio corrispondenti usati in locale in fase di esecuzione (in uno specifico tenant).

Per altre informazioni, vedere Oggetti applicazione e oggetti entità servizio in Azure Active Directory.

accesso

Processo con cui un'applicazione client avvia l'autenticazione dell'utente finale e acquisisce il relativo stato, allo scopo di acquisire un token di sicurezza e definire l'ambito della sessione dell'applicazione in base a tale stato. Lo stato può includere elementi come informazioni del profilo utente e informazioni derivate dalle attestazioni del token.

La funzione di accesso di un'applicazione viene in genere usata per implementare l'accesso Single Sign-On (SSO). Può anche essere preceduta da una funzione di "iscrizione" che rappresenta il punto di ingresso di un utente finale per accedere a un'applicazione (al primo accesso). La funzione di iscrizione viene usata per raccogliere e rendere persistente uno stato aggiuntivo specifico dell'utente e può richiedere il consenso dell'utente.

disconnessione

Processo con cui viene annullata l'autenticazione di un utente finale, rimuovendo lo stato utente associato alla sessione dell'applicazione client durante l'accesso

tenant

Un'istanza di una directory di Azure AD è definita tenant di Azure AD. Offre una serie di funzionalità, tra cui:

Un tenant è anche associato a una sottoscrizione di Azure AD o Office 365 durante il provisioning della sottoscrizione, fornendo funzionalità di gestione delle identità e degli accessi per la sottoscrizione. Per informazioni dettagliate sui vari modi in cui è possibile ottenere l'accesso a un tenant, vedere Come ottenere un tenant di Azure Active Directory. Per informazioni sulla relazione tra sottoscrizioni e un tenant di Azure AD, vedere Associare le sottoscrizioni di Azure ad Azure Active Directory.

endpoint di token

Uno degli endpoint implementati dal server di autorizzazione per supportare le concessioni di autorizzazione OAuth2. A seconda della concessione, può essere usato per acquisire un token di accesso (e un token di "aggiornamento" correlato) per un client oppure un token ID quando viene usato insieme al protocollo OpenID Connect.

client basato su agente utente

Tipo di applicazione client che scarica il codice da un server Web e viene eseguita all'interno di un agente utente (come un Web browser), ad esempio un'applicazione a singola pagina. Poiché tutto il codice viene eseguito in un dispositivo, il client viene considerato "pubblico" perché non può eseguire l'archiviazione privata/riservata delle credenziali. Per altri dettagli, vedere i profili e i tipi di client di OAuth2.

entità utente

Analogamente a un oggetto entità servizio che viene usato per rappresentare un'istanza dell'applicazione, un oggetto entità utente è un altro tipo di entità di sicurezza che rappresenta un utente. L'entità utente di Azure AD Graph definisce lo schema per un oggetto utente, incluse le proprietà relative all'utente come nome e cognome, nome dell'entità utente, appartenenza a un ruolo della directory e così via. La configurazione dell'identità utente per Azure AD può così stabilire un'entità utente in fase di esecuzione. L'entità utente viene usata per rappresentare un utente autenticato per Single Sign-On, durante la registrazione della delega del consenso, le decisioni di controllo di accesso e così via.

client Web

Tipo di applicazione client che esegue tutto il codice su un server Web e può funzionare come client "riservato" perché può eseguire l'archiviazione sicura delle credenziali sul server. Per altri dettagli, vedere i profili e i tipi di client di OAuth2.

Passaggi successivi

La Guida per gli sviluppatori di Azure Active Directory offre un portale da usare per tutti gli argomenti relativi allo sviluppo per Azure AD, ad esempio per una panoramica dell'integrazione di applicazioni e le nozioni di base sull'autenticazione in Azure AD e gli scenari di autenticazione supportati.

Usare la seguente sezione commenti per fornire commenti e suggerimenti per aiutarci a perfezionare e a definire il contenuto del glossario, incluse le richieste di nuove definizioni o l'aggiornamento di quelle esistenti.