Glossario: Microsoft Identity Platform
Queste condizioni verranno visualizzate quando si usa la documentazione, la portale di Azure, le librerie di autenticazione e microsoft API Graph. Alcuni termini sono specifici di Microsoft, mentre altri sono correlati a protocolli come OAuth o altre tecnologie usate con il Microsoft Identity Platform.
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 protetto. 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 validi solo per un breve periodo di tempo e non possono essere revocati. Un server di autorizzazione può anche emettere un token di aggiornamento quando viene rilasciato il token di accesso. I token di aggiornamento vengono in genere forniti solo alle applicazioni client riservate.
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 le informazioni di riferimento sui token di accesso .
Attore
Un altro termine per l'applicazione client. L'attore è l'entità che agisce per conto di un soggetto (proprietario della risorsa).
ID applicazione (client)
L'ID applicazione o l'ID client è un valore assegnato dal Microsoft Identity Platform all'applicazione quando viene registrato in Azure AD. L'ID applicazione è un valore GUID che identifica in modo univoco l'applicazione e la relativa configurazione all'interno della piattaforma di gestione delle identità. Aggiungere l'ID app al codice dell'applicazione e le librerie di autenticazione includono il valore nelle richieste alla piattaforma di gestione delle identità in fase di esecuzione dell'applicazione. L'ID applicazione (client) non è un segreto, non usarlo come password o altre credenziali.
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 con Azure AD, si fornisce una configurazione dell'identità per l'applicazione, consentendo l'integrazione con Azure AD e l'uso di funzionalità come:
- Gestione affidabile dell'accesso Single Sign-On con l'implementazione del protocollo OpenID Connect e la gestione delle identità di Azure AD
- Accesso negoziato alle risorse protette dalle applicazioni client, tramite il server di autorizzazione OAuth 2.0
- Framework di consenso per la gestione dell'accesso client alle risorse protette, in base all'autorizzazione del proprietario delle risorse
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 OAuth 2.0 , ad esempio, l'autenticazione dell'entità sta occupando il ruolo del proprietario della risorsa o dell'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.
- Durante un flusso di concessione di autorizzazione OAuth 2.0 : quando il proprietario della risorsa concede l'autorizzazione all'applicazione client, consentendo al client di accedere alle risorse del proprietario della risorsa.
- Durante l'accesso alle risorse da parte del client: l'implementazione viene eseguita dal server di risorse, usando i valori attestazione presenti nel token di accesso come base per le decisioni relative al controllo di accesso.
Codice di autorizzazione
Valore di breve durata fornito dall'endpoint di autorizzazione a un'applicazione client durante il flusso di concessione del codice di autorizzazione OAuth 2.0, uno dei quattro concessioni di autorizzazione OAuth 2.0. Detto anche codice di autenticazione, il codice di autorizzazione viene restituito all'applicazione client in risposta all'autenticazione di un proprietario della risorsa. Il codice di autenticazione indica che il proprietario della risorsa ha delegato l'autorizzazione all'applicazione client per accedere alle risorse. Come parte del flusso, il codice di autenticazione viene successivamente riscattato per un token di accesso.
Authorization endpoint (Endpoint di autorizzazione)
Uno degli endpoint implementati dal server di autorizzazione, usato per interagire con il proprietario della risorsa per fornire una concessione di autorizzazione durante un flusso di concessione di autorizzazione OAuth 2.0. 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 OAuth 2.0 e alla specifica OpenIDConnect .
Concessione di autorizzazione
Credenziale che rappresenta l'autorizzazione del proprietario delle risorse ad accedere alle risorse protette, concessa a un'applicazione client. Un'applicazione client può usare uno dei quattro tipi di concessione definiti dal framework di autorizzazione OAuth 2.0 per ottenere una concessione, a seconda del tipo di client/requisiti: "concessione del codice di autorizzazione", "concessione delle 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.
Serve autorizzazione
Come definito dal framework di autorizzazione OAuth 2.0, il server responsabile dell'emissione di token di accesso al client dopo aver autenticato correttamente il proprietario della risorsa e ottenuto l'autorizzazione. Un'applicazione client interagisce con il server di autorizzazione in fase di esecuzione tramite i relativi endpoint di autorizzazione e token, in conformità alle concessioni di autorizzazione definite da OAuth 2.0.
Nel caso dell'integrazione dell'applicazione Microsoft Identity Platform, il Microsoft Identity Platform implementa il ruolo del server di autorizzazione per le applicazioni di Azure AD e le API del servizio Microsoft, ad esempio le API di Microsoft Graph.
Attestazione
Le attestazioni sono coppie nome/valori in un token di sicurezza che forniscono asserzioni effettuate da un'entità a un'altra. Queste entità sono in genere l'applicazione client o un proprietario di risorse che fornisce asserzioni a un server di risorse. Attestazioni inoltri informazioni sull'oggetto del token, ad esempio l'ID dell'entità di sicurezza autenticata dal server di autorizzazione. Le attestazioni presenti in un token possono variare e dipendono da diversi fattori, ad esempio il tipo di token, il tipo di credenziale usato per autenticare l'oggetto, la configurazione dell'applicazione e altri.
Per altri dettagli, vedere le informazioni di riferimento sui token di Microsoft Identity Platform.
Applicazione client
Noto anche come "attore". Come definito dal framework di autorizzazione OAuth 2.0, un'applicazione che effettua richieste di risorse protette per conto del proprietario della risorsa. Ricevono le autorizzazioni dal proprietario della risorsa sotto forma di ambiti. Il termine "client" non implica particolari caratteristiche di implementazione hardware (ad esempio, se l'applicazione viene eseguita in un server, in un desktop o in altri dispositivi).
Un'applicazione client richiede l'autorizzazione da un proprietario della risorsa per partecipare a un flusso di concessione di autorizzazione OAuth 2.0 e può accedere alle API/ai dati per conto del proprietario della risorsa. Il framework di autorizzazione OAuth 2.0 definisce due tipi di client, "riservati" e "pubblici", in base alla capacità del client di mantenere la riservatezza delle 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.
Consenso
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.
Per altre informazioni, vedere framework di consenso.
token ID
Token di sicurezzaOpenID 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 in particolare al controllo di accesso.
Per altri dettagli, vedere le informazioni di riferimento sul token ID .
Identità gestite
Eliminare la necessità per gli sviluppatori di gestire le credenziali. Le identità gestite forniscono un'identità che le applicazioni possono usare per la connessione alle risorse che supportano l'autenticazione di Azure AD. Le applicazioni possono usare l'identità gestita per ottenere i token di Azure AD. Ad esempio, un'applicazione può usare un'identità gestita per accedere a risorse come Azure Key Vault in cui gli sviluppatori possono archiviare le credenziali in modo sicuro o per accedere agli account di archiviazione. Per altre informazioni, vedere Panoramica delle identità gestite.
Microsoft Identity Platform
Il Microsoft Identity Platform è un'evoluzione del servizio di gestione delle identità di Azure Active Directory (Azure AD) e della piattaforma per sviluppatori. Consente agli sviluppatori di creare applicazioni che supportano l'accesso per tutte le identità Microsoft e il recupero di token per chiamare Microsoft Graph, altre API Microsoft o API create dagli sviluppatori. Si tratta di una piattaforma completa costituita da un servizio di autenticazione, librerie, registrazione e configurazione dell'applicazione, documentazione completa per sviluppatori, esempi di codice e altro contenuto per sviluppatori. Microsoft Identity Platform supporta protocolli standard di settore come OAuth 2.0 e OpenID Connect.
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.
Native Client
Tipo di applicazione client che è installato in modo nativo in un dispositivo. Poiché tutto il codice viene eseguito in un dispositivo, viene considerato un client "pubblico" a causa dell'impossibilità di archiviare le credenziali privatamente/riservate. Per altri dettagli, vedere Tipi e profili client OAuth 2.0 .
Autorizzazioni
Un'applicazione client ottiene l'accesso a un server di risorse dichiarando richieste di autorizzazione. Sono disponibili due tipi:
- Le autorizzazioni "delegate", che richiedono l'accesso in base all'ambito con autorizzazione delegata dal proprietario delle risorse connesso, vengono presentate alla risorsa in fase di esecuzione sotto forma di attestazioni "scp" nel token di accesso del client. Questi indicano l'autorizzazione concessa all'attoredall'oggetto.
- Le autorizzazioni "applicazione", che richiedono l'accesso in base al ruolo con credenziali/identità dell'applicazione client, vengono presentate alla risorsa in fase di esecuzione sotto forma di attestazioni "roles" nel token di accesso del client. Questi indicano le autorizzazioni concesse all'oggetto dal tenant.
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 pagina Autorizzazioni API per un'applicazione nel portale di Azure, selezionando le autorizzazioni delegate desiderate e "Autorizzazioni applicazione" (quest'ultima richiede l'appartenenza al ruolo Global Amministrazione). 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.
Token di aggiornamento
Tipo di token di sicurezza rilasciato da un server di autorizzazione. Prima della scadenza di un token di accesso, un'applicazione client include il token di aggiornamento associato quando richiede un nuovo token di accesso dal server di autorizzazione. I token di aggiornamento vengono in genere formattati come token JSON Web (JWT).
A differenza dei token di accesso, è possibile revocare i token di aggiornamento. Un server di autorizzazione nega qualsiasi richiesta da un'applicazione client che include un token di aggiornamento revocato. Quando il server di autorizzazione nega una richiesta che include un token di aggiornamento revocato, l'applicazione client perde l'autorizzazione per accedere al server di risorse per conto del proprietario della risorsa.
Per altri dettagli, vedere i token di aggiornamento .
Proprietario della risorsa
Come definito dal framework di autorizzazione OAuth 2.0, un'entità in grado di concedere l'accesso a una risorsa protetta. Quando il proprietario della risorsa è una persona, viene definita 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. Il "proprietario della risorsa" viene talvolta chiamato anche oggetto.
Ogni token di sicurezza rappresenta un proprietario della risorsa. Il proprietario della risorsa è ciò che rappresenta l'attestazione dell'oggetto, l'attestazione ID oggetto e i dati personali nel token. I proprietari delle risorse sono la parte che concede autorizzazioni delegate a un'applicazione client, sotto forma di ambiti. I proprietari delle risorse sono anche i destinatari dei ruoli che indicano le autorizzazioni espanse all'interno di un tenant o in un'applicazione.
Server risorse
Come definito dal framework di autorizzazione OAuth 2.0, un server che ospita risorse protette, in grado di accettare e rispondere alle richieste di risorse protette 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 microsoft API Graph, che fornisce l'accesso ai dati del tenant di Azure AD e le API Microsoft 365 che forniscono l'accesso ai dati, ad esempio posta e calendario.
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, ad esempio Microsoft API Graph, hanno entità servizio preregistrato rese disponibili in tutti i tenant durante il provisioning.
Ruoli
Analogamente agli ambiti, i ruoli dell'app consentono a un server di risorse di gestire l'accesso alle risorse protette. A differenza degli ambiti, i ruoli rappresentano i privilegi concessi dall'oggetto oltre la baseline. Questo è il motivo per cui la lettura del proprio messaggio di posta elettronica è un ambito, mentre l'amministratore di posta elettronica in grado di leggere la posta elettronica di tutti è un ruolo.
I ruoli dell'app possono supportare due tipi di assegnazione: l'assegnazione "utente" implementa il controllo degli accessi in base al ruolo per utenti/gruppi che richiedono l'accesso alla risorsa, mentre l'assegnazione "applicazione" implementa lo stesso per le applicazioni client che richiedono l'accesso. Un ruolo dell'app può essere definito come assegnabile dall'utente, app-assignabnle o entrambi.
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 assegnabili "utente" e configurare le autorizzazioni dell'applicazione client per richiedere ruoli assegnabili "applicazione".
Per una descrizione dettagliata dei ruoli applicazione esposti da Microsoft API Graph, vedere API Graph Ambiti di autorizzazione. Per un esempio dettagliato di implementazione, vedere Aggiungere o rimuovere assegnazioni di ruolo di Azure usando il portale di Azure.
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 da Microsoft API Graph, vedere API Graph Ambiti di autorizzazione. Per gli ambiti esposti dai servizi di Microsoft 365, vedere informazioni di riferimento sulle autorizzazioni api Microsoft 365.
Token di sicurezza
Documento firmato contenente attestazioni, ad esempio un token OAuth 2.0 o un'asserzione SAML 2.0. Per una concessione di autorizzazione OAuth 2.0, un token di accesso (OAuth2), un token di aggiornamento e un token ID sono tipi di token di sicurezza, tutti implementati come token JSON Web (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 tale 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 di un'applicazione client che avvia l'autenticazione dell'utente finale e acquisisce lo stato correlato per richiedere un token di sicurezza e definire l'ambito della sessione dell'applicazione a tale stato. Lo stato può includere artefatti come informazioni sul profilo utente e informazioni derivate dalle attestazioni 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
Oggetto
Noto anche come proprietario della risorsa.
Tenant
Un'istanza di una directory di Azure AD è definita tenant di Azure AD. Fornisce diverse funzionalità, tra cui:
- un servizio di registro per applicazioni integrate
- autenticazione di account utente e applicazioni registrate
- Endpoint REST necessari per supportare diversi protocolli, tra cui OAuth 2.0 e SAML, tra cui l'endpoint di autorizzazione, l'endpoint del token e l'endpoint "comune" usato dalle applicazioni multi-tenant.
I tenant di Azure AD vengono creati/associati ad Azure e alle sottoscrizioni Microsoft 365 durante l'iscrizione, fornendo funzionalità di Gestione degli accessi alle identità & per la sottoscrizione. Gli amministratori delle sottoscrizioni di Azure inoltre possono creare altri tenant di Azure AD tramite il portale di Azure. Per informazioni dettagliate sui vari modi in cui è possibile ottenere l'accesso a un tenant, vedere Come ottenere un tenant di Azure Active Directory. Vedere Associare o aggiungere una sottoscrizione di Azure al tenant Azure Active Directory per informazioni dettagliate sulla relazione tra sottoscrizioni e un tenant di Azure AD e per istruzioni su come associare o aggiungere una sottoscrizione a un tenant di Azure AD.
Token endpoint (Endpoint di token)
Uno degli endpoint implementati dal server di autorizzazione per supportare le concessioni di autorizzazione OAuth 2.0. 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 pagina singola. 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 altre informazioni, vedere Tipi e profili client OAuth 2.0.
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. Il tipo di risorsa Utente di Microsoft Graph definisce lo schema per un oggetto utente, incluse le proprietà correlate all'utente, ad esempio nome e cognome, nome dell'entità utente, appartenenza al ruolo della directory e così via. In questo modo viene fornita la configurazione dell'identità utente per Azure AD per 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 in un server Web, funzionante come client riservato perché può archiviare in modo sicuro le credenziali nel server. Per altre informazioni, vedere Tipi e profili client OAuth 2.0.
Identità del carico di lavoro
Identità usata da un carico di lavoro software come un'applicazione, un servizio, uno script o un contenitore per autenticare e accedere ad altri servizi e risorse. In Azure AD le identità del carico di lavoro sono app, entità servizio e identità gestite. Per altre informazioni, vedere Panoramica dell'identità del carico di lavoro.
Federazione delle identità del carico di lavoro
Consente di accedere in modo sicuro alle risorse protette di Azure AD da app e servizi esterni senza dover gestire i segreti (per scenari supportati). Per altre informazioni, vedere Federazione delle identità del carico di lavoro.
Passaggi successivi
Molti dei termini di questo glossario sono correlati ai protocolli OAuth 2.0 e OpenID Connessione. Anche se non è necessario conoscere il funzionamento dei protocolli "sul filo" per l'uso della piattaforma identity, sapendo che alcune nozioni di base sul protocollo consentono di creare e eseguire il debug più facilmente dell'autenticazione e dell'autorizzazione nelle app: