Condividi tramite

Glossario: Microsoft Identity Platform

  • Articolo

Questi termini vengono visualizzati quando si usa la documentazione, l'interfaccia di amministrazione di Microsoft Entra, le librerie di autenticazione e l'API Microsoft Graph. Alcuni termini sono specifici di Microsoft, mentre altri sono correlati a protocolli come OAuth o altre tecnologie usate con 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 da Microsoft Identity Platform all'applicazione al momento della registrazione in Microsoft Entra ID. L'ID applicazione è un valore GUID che identifica in modo univoco l'applicazione e la relativa configurazione all'interno di Identity Platform. 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

Un manifesto dell'applicazione è una funzionalità che produce una rappresentazione JSON della configurazione dell'identità dell'applicazione, usata come meccanismo per aggiornare le entità Application e ServicePrincipal associate. Per altre informazioni, vedere Informazioni sul manifesto dell'applicazione Microsoft Entra.

Oggetto applicazione

Quando si registra/aggiorna un'applicazione, vengono creati/aggiornati 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 (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 di integrarsi con e delegare le funzioni di gestione delle identità e degli accessi a Microsoft Entra ID, è necessario registrarla con un tenant di Microsoft Entra. Quando si registra l'applicazione con Microsoft Entra ID, si fornisce una configurazione di identità per l'applicazione, consentendo l'integrazione con Microsoft Entra ID e l'uso di funzionalità come:

Per altri dettagli, vedere Integrazione di applicazioni con Microsoft Entra ID .

Autenticazione

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. Esistono due casi d'uso principali nel modello di programmazione Microsoft Entra:

  • 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 della risorsa ad accedere alle risorse protette, concesse 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 o dei requisiti del client: "concessione del codice di autorizzazione", "concessione di credenziali client", "concessione implicita" e "concessione di 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.

La concessione delle credenziali della password del proprietario della risorsa non deve essere usata tranne negli scenari in cui non è possibile usare altri flussi. Se si compila un'applicazione a pagina singola, usare il flusso del codice di autorizzazione con PKCE anziché una concessione implicita.

Serve autorizzazione

Come definito dal framework di autorizzazione OAuth 2.0, il server responsabile del rilascio 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 gli 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, Microsoft Identity Platform implementa il ruolo del server di autorizzazione per le applicazioni Microsoft Entra e le API del servizio Microsoft, ad esempio le API Microsoft Graph.

Richiesta di rimborso

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 l'autenticazione dell'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 a API/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 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.

Per altre informazioni, vedere framework di 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 della risorsa dell'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à per le applicazioni da usare per la connessione alle risorse che supportano l'autenticazione di Microsoft Entra. Le applicazioni possono usare l'identità gestita per ottenere token di Microsoft Identity Platform. 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

Microsoft Identity Platform è un'evoluzione del servizio di gestione delle identità Microsoft Entra 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 altri contenuti per sviluppatori. Microsoft Identity Platform supporta protocolli standard di settore come OAuth 2.0 e OpenID Connect.

Applicazione multi-tenant

Classe di applicazione che abilita l'accesso e il consenso da parte degli utenti di cui è stato effettuato il provisioning in qualsiasi tenant di Microsoft Entra, inclusi i tenant diversi da quello in cui è registrato il client. 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 accedere a qualsiasi utente di Microsoft Entra 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, è considerato un client "pubblico" a causa dell'impossibilità di archiviare le credenziali privatamente/riservato. 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'attore dall'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 selezionando le autorizzazioni delegate desiderate e "Autorizzazioni applicazione" (quest'ultima richiede l'appartenenza al ruolo Amministratore globale). 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 emesso 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, i token di aggiornamento possono essere revocati. 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 delle 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 rappresenta l'attestazione dell'oggetto, l'attestazione ID oggetto e i dati personali nel token. I proprietari delle risorse sono le parti che concedono 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 l'API Microsoft Graph, che fornisce l'accesso ai dati del tenant di Microsoft Entra e le API di Microsoft 365 che forniscono l'accesso ai dati, ad esempio posta e calendario.

Proprio come un'applicazione client, la configurazione dell'identità dell'applicazione di risorse viene stabilita tramite la registrazione in un tenant di Microsoft Entra, fornendo sia l'applicazione che l'oggetto entità servizio. Alcune API fornite da Microsoft, ad esempio l'API Microsoft 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. Per questo motivo 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 dalle risorse (ad esempio "Responsabile approvazione spese", "Sola lettura", "Directory.ReadWrite.All"), gestite tramite il manifesto dell'applicazione della risorsa e archiviate nella proprietà appRoles della risorsa. Gli utenti possono essere assegnati a ruoli assegnabili "utente" e le autorizzazioni dell'applicazione client possono essere configurate per richiedere ruoli assegnabili "applicazione".

Per una descrizione dettagliata dei ruoli dell'applicazione esposti dall'API Microsoft Graph, vedere Ambiti di autorizzazione api Graph. Per un esempio dettagliato di implementazione, vedere Aggiungere o rimuovere assegnazioni di ruolo 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 dalla risorsa (ad esempio "Mail.Read", "Directory.ReadWrite.All"), gestite tramite il manifesto dell'applicazione della risorsa e archiviate nella proprietà oauth2Permissions della risorsa. Le autorizzazioni delegate dell'applicazione client possono essere configurate per accedere 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 Microsoft Graph, vedere Ambiti di autorizzazione api Graph. Per gli ambiti esposti dai servizi Microsoft 365, vedere Informazioni di riferimento sulle autorizzazioni api di 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, vengono creati/aggiornati 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.

Accedi

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

Oggetto

Noto anche come proprietario della risorsa.

Tenant

Un'istanza di una directory di Microsoft Entra viene definita tenant di Microsoft Entra. Fornisce diverse funzionalità, tra cui:

  • un servizio di registro per applicazioni integrate
  • autenticazione di account utente e applicazioni registrate
  • Endpoint REST necessari per supportare vari protocolli, tra cui OAuth 2.0 e SAML, tra cui l'endpoint di autorizzazione, l'endpoint token e l'endpoint "comune" usato dalle applicazioni multi-tenant.

I tenant di Microsoft Entra vengono creati/associati alle sottoscrizioni di Azure e Microsoft 365 durante l'iscrizione, fornendo funzionalità di gestione delle identità e degli accessi per la sottoscrizione. Gli amministratori delle sottoscrizioni di Azure possono anche creare tenant Microsoft Entra aggiuntivi. Per informazioni dettagliate sui vari modi in cui è possibile accedere a un tenant, vedere Come ottenere un tenant di Microsoft Entra. Vedere Associare o aggiungere una sottoscrizione di Azure al tenant di Microsoft Entra per informazioni dettagliate sulla relazione tra sottoscrizioni e un tenant di Microsoft Entra e per istruzioni su come associare o aggiungere una sottoscrizione a un tenant di Microsoft Entra.

Endpoint 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, è considerato un client "pubblico" a causa dell'impossibilità di archiviare le credenziali privatamente/riservato. 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 Microsoft Graph User 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 Microsoft Entra ID per stabilire un'entità utente in fase di esecuzione. L'entità utente viene usata per rappresentare un utente autenticato per l'accesso Single Sign-On, registrare la delega del consenso , prendere decisioni di controllo di accesso e così via.

Client Web

Tipo di applicazione client che esegue tutto il codice in un server Web, che funziona 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 Microsoft Entra ID 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 Microsoft Entra 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 Connect. Anche se non è necessario sapere come funzionano i protocolli "in transito" per usare la piattaforma delle identità, conoscere alcune nozioni di base del protocollo può aiutare a creare ed eseguire più facilmente il debug di autenticazione e autorizzazione nelle app: