Microsoft Entra ID, che prima conoscevamo come Azure Active Directory, è uno strumento utile per gestire identità e accessi nel cloud e non solo.

In Microsoft Entra ID ci sono due rappresentazioni delle applicazioni: App Registration ed Enterprise Application.

Questi due elementi spesso confondono molti amministratori. Sono componenti essenziali per configurare applicazioni che interagiscono con i servizi Azure o con altre applicazioni. Ognuna ha il suo scopo specifico nel configurare l'applicazione.

Aggiungendo le applicazioni a Microsoft Entra ID, puoi sfruttare uno o più servizi, come:

• Autenticazione e autorizzazione delle applicazioni;
• Autenticazione e autorizzazione degli utenti;
• Accesso Single Sign-On (SSO) tramite federazione o password;
• Provisioning e sincronizzazione degli utenti;
• Controllo degli accessi in base al ruolo: usare la directory per definire i ruoli applicazione al fine di eseguire i controlli di autorizzazione in base al ruolo in un'applicazione;
• Servizi di autorizzazione OAuth: servizi usati da Microsoft 365 e altre applicazioni Microsoft per autorizzare l'accesso ad API e risorse;
• Proxy e pubblicazione delle applicazioni: pubblicare un'applicazione in Internet da una rete privata;
• Attributi dell'estensione dello schema della directory: estendere lo schema delle entità servizio e degli oggetti utente per archiviare dati aggiuntivi in Microsoft Entra ID.

 

Il Single Sign-On (SSO) permette agli utenti di autenticarsi una sola volta e poi di accedere automaticamente a varie risorse senza dover reinserire le credenziali. Una volta autenticato, il sistema IAM diventa il punto di riferimento per l’identità dell’utente per tutte le altre risorse disponibili. Questo significa che non devi più accedere a sistemi separati ogni volta.

Lo scopo di queste risorse è quello di consentire la registrazione dell'applicazione o del servizio con Entra ID.  Questo crea una sorta di fiducia tra l'app e la piattaforma di identità di Microsoft.

Si tratta di una fiducia unidirezionale: l'app si fida della piattaforma di identità, non il contrario.

Autenticazione e Autorizzazione

I termini autenticazione e autorizzazione vengono talvolta usati in modo intercambiabile, perché spesso sembrano un'unica esperienza per gli utenti.

Sono in realtà due processi separati:

1. L'autenticazione dimostra l'identità di un utente, di un computer o di un componente software;
2. L'autorizzazione concede o nega l'accesso a determinate risorse all'utente, al computer o al componente software.

Autenticazione	Autorizzazione
Può essere considerato un gatekeeper, che consente l'accesso solo alle entità che forniscono credenziali valide.	Può essere considerato come una guardia, che assicura che solo le entità con le autorizzazioni adeguate possano accedere a determinate aree.
Verifica se un utente, un computer o un software è chi o cosa dichiara di essere.	Determina se l'utente, il computer o il software è autorizzato ad accedere a una determinata risorsa.
Sfida l'utente, la macchina o il software a fornire credenziali verificabili (ad esempio, password, identificatori biometrici o certificati).	Determina il livello di accesso di un utente, un computer o un software.
Operazione eseguita prima dell'autorizzazione.	Operazione eseguita dopo una corretta autenticazione.
Le informazioni vengono trasferite in un token ID.	Le informazioni vengono trasferite in un token di accesso.
Spesso utilizza i protocolli OpenID Connect (OIDC) (basati sul protocollo OAuth 2.0) o SAML.	Spesso usa il protocollo OAuth 2.0.

In inglese, "autenticazione" è spesso abbreviato in AuthN e "autorizzazione" in AuthZ.

Tenancy

Microsoft Entra organizza gli oggetti come utenti, gruppi, app e configurazioni dell’organizzazione in tenant. I tenant consentono a un amministratore di impostare criteri all'interno dell'organizzazione per soddisfare i criteri operativi e di sicurezza.

Un tenant è un'istanza specifica di Entra ID, viene creato automaticamente la prima volta che si sottoscrive un abbonamento a un servizio cloud Microsoft. Da lì, definisce logicamente l'organizzazione all'interno del servizio.

Service Principal

Un Service Principal in ambito Microsoft è un'identità che puoi assegnare a un'applicazione o un servizio piuttosto che a un utente. Questa identità consente di autenticare e autorizzare l'accesso a risorse in modo sicuro (principio di sicurezza che definisce le autorizzazioni).

In parole povere, non sono altro che le vostre “applicazioni aziendali” (o la loro rappresentazione all'interno della directory).

Immagina di avere un'applicazione web che ha bisogno di accedere a un database su Azure per recuperare e salvare dati. Invece di salvare le credenziali di un utente amministratore nell'app (cosa poco sicura), crei un Service Principal per l'applicazione. Questo Service Principal ottiene solo i permessi necessari per accedere al database e nient'altro.

Gli utenti sono un altro tipo di principio di sicurezza: assegniamo permessi e ruoli agli utenti all'interno di Entra ID, così come ad altre risorse associate.

Si deve sottolineare "permessi consentiti" perché, mentre la registrazione dell'applicazione definisce i permessi di cui lo sviluppatore ha bisogno per il funzionamento dell'applicazione, è il service principal che definisce effettivamente ciò che è consentito nel tenant. Il service principal è anche l'oggetto che apparirà in vari “elenchi di scelta” di Azure, se state applicando qualcosa come un criterio di accesso condizionato o assegnando i diritti del service principal in una sottoscrizione Azure.

Microsoft Graph: Il gateway per i dati

Microsoft Graph è un endpoint API unificato che fornisce l'accesso a vari servizi di Microsoft 365/Azure.

È spesso coinvolto nella gestione delle autorizzazioni di registrazione delle app, soprattutto quando si accede ai dati della suite.

• Modello di dati unificato: Microsoft Graph presenta i dati provenienti da vari servizi utilizzando uno schema coerente e unificato. Ciò significa che, sia che si acceda ai dati degli utenti da Azure AD o ai file da OneDrive, la struttura e l'approccio rimangono coerenti.
• Approfondimenti intelligenti: Oltre al semplice accesso ai dati, Microsoft Graph offre approfondimenti derivati dai modelli presenti nei dati. Ad esempio, può suggerire gli orari delle riunioni in base ai calendari dei partecipanti o consigliare i file in base all'attività degli utenti.
• Query Delta: Questa funzione consente alle applicazioni di riconoscere le modifiche dei dati rispetto all'ultima richiesta, rendendo efficiente l'aggiornamento delle applicazioni con i dati più recenti senza un eccessivo polling.
• Webhook: Microsoft Graph supporta le notifiche in tempo reale. Invece di eseguire costantemente il polling per le modifiche dei dati, le applicazioni possono sottoscrivere modifiche specifiche dei dati e ricevere notifiche istantanee.

Cos'è un'App Registration?

Un’App Registration è un modello o scheletro di un’applicazione che si registra nella directory di Microsoft Entra ID.

Essa descrive come un'applicazione interagisce con Entra ID e definisce:

• Identità unica dell'applicazione, viene assegnato un ID applicazione (client ID)

• Permessi richiesti per accedere alle API (sia di Microsoft che personalizzate)

• Configurazioni di autenticazione, come redirect URI o certificati o segreti (password)

  • L'applicazione passerà le credenziali, ad esempio tramite un client secret o un certificato, ad Entra ID per dimostrare la propria identità e quindi richiedere i token

• Permette di definire quali sono le API di Microsoft Graph o di altro tipo a cui l'applicazione deve accedere

  • Definire l'ambito: Con quali API deve interagire la vostra applicazione (es. Microsoft Graph)? Che tipo di permessi/ambito di applicazione API richiede la vostra applicazione (es. User.ReadWrite.All, User.Read)?
  • Permessi dell'applicazione o permessi delegati: L'applicazione può utilizzare i propri permessi (permessi dell'applicazione) [OPPURE] i permessi dell'utente (delegato) per accedere alle risorse di Azure?

• Per default sono basate su OAuth 2.0 e OpenID Connect

In pratica, quando vuoi creare un'applicazione che si autentica tramite Microsoft Entra ID o accede a risorse protette, registri prima questa app in Entra ID come App Registration.

Questo permette all'applicazione di autenticarsi e richiedere permissions.

A cosa serve?

Le registrazioni di app generalmente sono utilizzate per registrare applicazioni personalizzate o di terze parti che non sono pre-integrate con Microsoft Entra ID.

• Quando sviluppi da zero un'applicazione che deve gestire autenticazioni (es. login con account di Microsoft Entra ID);
• Definizione delle API che l'applicazione può chiamare;
• Configurazione di ambiti (scopes) come `User.Read` per autorizzare le risorse.

Cos'è una Enterprise App?

Un’Enterprise Application è un'istanza o configurazione specifica di un’App Registration (linked instance) all'interno di una directory aziendale.

Viene creata automaticamente quando:

• Un’app esterna (tipicamente SaaS multi-tenant, come Salesforce o Google Workspace) è aggiunta alla directory;
• Un’app sviluppata internamente (registrata come App Registration) è distribuita.

Caratteristiche principali:

• Configura come l'applicazione interagisce con gli utenti e i gruppi all'interno dell'azienda. E' legata a un Service Principal, che definisce le autorizzazioni e i criteri specifici per quell'applicazione all'interno di un tenant;
• Consente di gestire l’assegnazione di utenti e gruppi autorizzati ad accedere all’app;
• Fornisce dettagli di come la federazione di autenticazione funziona tra la directory Microsoft Entra ID e l'applicazione (ad esempio: SSO);
• Può condividere l'application ID dell'App Registration;

• Si possono applicare politiche di accesso condizionale.

Quando un'organizzazione aggiunge un'Enterprise App a Microsoft Entra ID, crea un oggetto Service Principal che rappresenta l'applicazione all'interno della directory. L'oggetto Service Principal viene quindi utilizzato per gestire le autorizzazioni di accesso dell'applicazione, assegnare utenti e gruppi e configurare le impostazioni di single sign-on (SSO) e altre impostazioni di autenticazione.

L’Enterprise Application rappresenta quindi l’implementazione pratica e configurata di un’app per un’organizzazione specifica.

Per un'applicazione single-tenant, una Enterprise App con lo stesso nome viene creata automaticamente dopo la registrazione dell'applicazione.

 

Alcune delle cose che potete fare o definire per la vostra applicazione a livello di Enterprise App includono (non è un elenco esaustivo):

• Nome o logo personalizzato che avrà la precedenza sul nome o sul logo definito a livello di registrazione dell'applicazione;
• Assegnare utenti o gruppi dal vostro Entra ID ai ruoli dell'applicazione (ricordate che i ruoli dell'applicazione sono definiti a livello di registrazione dell'applicazione);
• Tenere traccia di chi ha acconsentito alle autorizzazioni richieste dall'applicazione;
• È possibile assegnare il Service Principal ai ruoli RBAC di Azure e quindi concedere i permessi alle risorse della sottoscrizione.

Nella maggior parte dei casi, le registrazioni di app e le applicazioni aziendali vanno di pari passo. Quando si dispone di una, si dispone anche dell'altra.

Relazione tra Oggetto Applicazione ed Entità Servizio

L'App Registration rappresenta fondamentalmente l'applicazione a livello globale, pensata per essere utilizzata in tutti i tenant, mentre l'Enterprise App è la versione locale, pensata per un tenant specifico.

L'App Registration serve come modello, da cui si estraggono le proprietà comuni e predefinite che vengono utilizzate per creare gli oggetti Enterprise App corrispondenti.

Quando parliamo di App Registration, possiamo distinguere:

• una relazione 1:1 con l'applicazione software, e
• una relazione 1:N con l'oggetto o gli oggetti entità servizio associati.

Ogni tenant in cui si utilizza l'applicazione deve avere un'entità servizio, che serve a stabilire un'identità per l'iscrizione e/o per l'accesso alle risorse protette da quel tenant.

Un'applicazione single-tenant avrà solamente un'entità servizio, creata e autorizzata per essere utilizzata al momento della registrazione dell'applicazione.

D'altra parte, un'applicazione multi-tenant avrà un'entità servizio creata in ciascun tenant in cui gli utenti hanno dato il loro consenso all'uso.

Multi-tenant

Supponiamo di aver creato e registrato un'applicazione multi-tenant chiamata demo-app nel Tenant A. Come parte del processo di registrazione, viene creato un oggetto applicazione globale (sotto App Registration) e un oggetto Service Principal locale (sotto Enterprise Apps).

I tenant B e C vogliono consumare la demo-app. Dopo aver fornito il link valido all'applicazione demo a questi consumatori, si procederà con il processo di consenso. Le autorizzazioni dell'ambito impostate nella definizione della demo-app saranno visualizzate nella richiesta di consenso, in cui si chiede all'amministratore di concedere le autorizzazioni su risorse specifiche.

Nota a margine: l'applicazione potrebbe essere configurata/progettata per consentire il consenso degli utenti per l'uso individuale. Se l'applicazione è configurata per consentire il consenso dell'amministratore, è stata progettata principalmente per l'intero tenant.

Una volta approvato il consenso, nel tenant del consumatore viene creato solo l'oggetto Service Principal e NON l'oggetto dell'applicazione.

Ci sarà un SOLO oggetto applicazione che risiede nel tenant A. Gli oggetti Service Principal creati nei tenant B e C non sono altro che una rappresentazione locale dell'oggetto applicazione del tenant A, unico a livello globale, a cui si fa riferimento tramite l'ID applicazione (client).

Ogni App Registration avrà una Service Principal corrispondente?

Sì, ma non necessariamente nel tuo tenant.

Per essere più specifici, è importante capire che le applicazioni enterprise sono più di semplici applicazioni OAuth 2.0/OIDC.

Se l'applicazione è OpenID Connect o OAuth 2.0, come abbiamo visto sopra, il tenant della risorsa avrà solo un servizio principale nel tenant di origine delle applicazioni.

Tuttavia, può succedere che quando crei un'applicazione enterprise, una registrazione dell'app associata apparirà nel tuo tenant. In realtà, qualsiasi applicazione aggiungi dalle applicazioni enterprise – SAML, Linked, basate su password o tramite Entra Application Proxy, creerà tutte una registrazione dell'app associata. Perché? Perché il servizio principale non è stato progettato per contenere tutte le informazioni che definiscono l'app (ritorniamo alla nostra definizione di App Registration).

Puoi aggiungere un'applicazione SAML in Entra ID, e poi andare alla sua registrazione dell'app corrispondente e guardare il manifest.

Se hai integrato determinate applicazioni SAML e desideri assegnare gruppi a ruoli personalizzati per poi emetterli nella risposta SAML, dovresti andare nella registrazione dell'app per definirli ulteriormente.

Ma fai attenzione che, da un punto di vista dei permessi, tornando al lato del service principal, è nell'applicazione enterprise che configuri chi è autorizzato ad accedere all'applicazione.

Differenze principali

Caratteristica	App Registration	Enterprise Application
Definizione	Modello di base che definisce un’applicazione in Entra ID.	Istanza configurata di una App Registration.
Scopo	Usato dagli sviluppatori per configurare un’app.	Usato dagli amministratori per gestire l'accesso aziendale.
Multi-tenant	Può essere configurata single-tenant o multi-tenant.	È legata alla directory e all’organizzazione specifica.
Assegnazione utenti/gruppi	Non configurabile direttamente in App Registration.	Permette di assegnare o limitare utenti e gruppi.
Creazione manuale	Deve essere registrata manualmente.	Si genera automaticamente quando l'app è associata.

Scenari pratici di utilizzo

App Registration

• Creazione di un’app personalizzata: Sei uno sviluppatore che crea un’applicazione interna da distribuire su Microsoft 365, quindi registri l’app per definire la sua identità e le API da utilizzare;
• Utilizzo di API Microsoft: Vuoi creare script o automazioni che leggono dati da Microsoft Graph API. Crei una App Registration per autenticare il client e ottenere un token.

Enterprise App

• Accesso ad app di terze parti: Un amministratore vuole permettere agli utenti dell’azienda di accedere a Zoom o Dropbox senza dover gestire credenziali aggiuntive. Aggiunge la relativa Enterprise Application in modalità single sign-on (SSO);
• Gestione delle autorizzazioni: Dopo aver distribuito un’app personalizzata, vuoi assegnare soltanto un gruppo specifico di utenti aziendali per accedere a quell’app. Questo viene fatto tramite la relativa Enterprise Application.

Configurare l'autenticazione dell'app

Le impostazioni per ogni tipo di applicazione, inclusi gli URI di reindirizzamento, sono configurate nelle configurazioni della piattaforma nel portale di Entra.

Con alcune piattaforme, ad esempio le applicazioni Web e a pagina singola, è necessario specificare manualmente un URI di reindirizzamento. Per altre piattaforme, ad esempio per applicazioni desktop e per dispositivi mobili, è possibile scegliere tra gli URI di reindirizzamento generati quando si configurano le altre impostazioni di tali piattaforme.

URI di reindirizzamento

Un URI di reindirizzamento (Redirect URI), o URL di risposta (Reply URL), è il percorso in cui il server di autorizzazione invia l'utente una volta che l'app è stata autorizzata con successo e gli è stato concesso un codice di autorizzazione o token di accesso.

Il server di autorizzazione invia il codice o il token all'URI di reindirizzamento, quindi è importante registrare la posizione corretta come parte del processo di registrazione dell'app.

API permission, Expose API

• Esporre un'API: Si concentra sulla configurazione delle API proprietarie di un'applicazione che altre applicazioni possono chiamare. Si creano ambiti specifici per definire operazioni o dati che l'API espone;
• Impostare le API Permissions: Si concentra sulle autorizzazioni che un'applicazione client richiede per accedere ad altre API già esistenti (come Microsoft Graph o API di altri servizi registrati in Entra ID).

API permissions

La comprensione dei permessi API è fondamentale, in quanto fa luce sulle implicazioni di sicurezza delle registrazioni di app e delle applicazioni aziendali. Poiché un Enterprise App è legata all'App Registration nel tenant, da dove dobbiamo iniziare a configurare i permessi? Naturalmente dall'App Registration.

È possibile scegliere tra due autorizzazioni API:

1. Le autorizzazioni delegate necessitano dei diritti dell'utente per funzionare. Verranno utilizzati i diritti dell'utente che ha effettuato l'accesso. Se l'utente non ha diritti sufficienti, l'applicazione non avrà accesso. Se l'utente ha diritti sufficienti ed è connesso, l'applicazione avrà accesso per conto dell'utente.

   • Configurare l'autorizzazione delegata per Microsoft Graph per consentire all'applicazione client di eseguire operazioni per conto dell'utente connesso, ad esempio la lettura della posta elettronica o la modifica del profilo.

2. Le autorizzazioni dell'applicazione danno i diritti al servizio stesso. Non c'è interazione con l'utente.

Gli sviluppatori dovrebbero sempre seguire il principio del privilegio minimo, chiedendo solo le autorizzazioni necessarie per il funzionamento dell'applicazione.

 

Obiettivo: Richiedere autorizzazioni necessarie per un'applicazione client per accedere alle API esposte da altre applicazioni.

Scenario di Esempio: Un'applicazione client, come un portale web HR (client), necessita di accedere alla Graph API per leggere le informazioni del profilo dell'utente e i dati della casella di posta elettronica. Durante la registrazione dell'app, vengono specificate le API permissions necessarie (es. User.Read, Mail.Read), che devono essere approvate dall’amministratore di Microsoft Entra ID per permettere l'accesso.

Senza autorizzazioni, la registrazione dell'app non può accedere a nulla e sarebbe solo un segnaposto.

Expose API

Immagina che la tua azienda disponga di un portale HR accessibile sia via web che tramite un'app mobile. Questo portale HR consente ai dipendenti di vedere i loro dati personali, gestire le richieste di ferie e accedere ai documenti aziendali.

Per garantire che solo gli utenti autorizzati possano accedere a queste funzionalità, e farlo in maniera sicura, decidi di integrare la piattaforma con Microsoft Entra ID usando la funzionalità di “Esporre un'API”.

1. App Web/Mobile: Il portale HR (accessibile via web e app mobile) utilizzato dai dipendenti.
2. Microsoft Entra ID: Il sistema di gestione delle identità che autentica gli utenti e autorizza l'accesso alle API.
3. API HR: L'API che gestisce l'accesso ai dati e alle funzionalità del portale HR.

 

Passaggi Tecnici e Utilizzo della Funzionalità di Esporre un'API

1. Registrazione dell'API HR su Entra ID

• Registri l'API del portale HR in Microsoft Entra ID.
• Configuri la registrazione dell'app e esponi gli ambiti necessari (Employees.Read.All, Employees.Write.All).

2. Definizione degli Ambiti

• Crei ambiti specifici che descrivono le operazioni consentite sull'API:

  • Employees.Read.All: Permette la lettura dei dati del dipendente.
  • Employees.Write.All: Permette la modifica dei dati del dipendente.

3. Creazione di una Registrazione per l’App Client

• Registri l’app web/mobile che fungerà da client dell’API, autorizzando questa app a richiedere i token necessari agli ambiti definiti.

4. Configurazione delle Autorizzazioni

• Pre-autorizzi l'app client per gli ambiti definiti in modo che non sia necessario un consenso esplicito da parte degli utenti.

5. Implementazione nel Codice dell'App Client

• Integra il flusso di autenticazione OAuth 2.0 nella tua app web/mobile.
• Durante il login, l'app richiede i token di accesso includendo gli ambiti necessari (Employees.Read.All, Employees.Write.All).

6. Esecuzione di Operazioni sull'API

• Quando l'utente interagisce con l’app, per esempio richiedendo i propri dati, l’app client invia una richiesta all'API Hr includendo il token di accesso ottenuto.
• L'API HR valida il token e verifica se gli ambiti inclusi nel token consentono l'operazione (ad esempio, se il token include Employees.Read.All per leggere i dati).

Flusso

1. Mario apre l'app mobile e si autentica tramite Entra ID.
2. Microsoft Entra ID verifica le credenziali di Mario e fornisce un token di accesso contenente Employees.Read.All.
3. L'app mobile invia una richiesta all'API HR per ottenere i dati del profilo di Mario, includendo il token di accesso.
4. L'API HR valida il token e verifica che l’ambito Employees.Read.All permetta la richiesta.
5. L'API risponde con i dati richiesti, che vengono presentati a Mario attraverso l’interfaccia della app mobile.

 

Obiettivo: Definire e gestire gli ambiti (scopes) che un'API espone per consentire altre applicazioni di fare richieste a essa.

Funzionalità principali:

1. Definizione degli Ambiti: Creare ambiti che rappresentano specifiche operazioni o accessi (es. Employees.Read.All per leggere i dati dei dipendenti).
2. Configurazione degli URI: Impostare URI unici che identificano gli ambiti esposti.
3. Pre-autorizzazione delle Client App: Pre-autorizzare le applicazioni client affidabili per accedere agli ambiti senza richiedere il consenso esplicito di ogni utente.

 

Scenario di Esempio: Quando sviluppi un’API che fornisce dati sui dipendenti e desideri che solo applicazioni specifiche possano accedere a queste informazioni tramite ambiti predefiniti (Employees.Read.All, Employees.Write.All), esporre l'API permette di specificare chiaramente quali operazioni possono essere eseguite e da chi.

Una convenzione di denominazione standard è per l’ambito tipicamente usata è resource.operation.constraint.

Grant Consent

Con le impostazioni predefinite di Entra ID, le persone dell'organizzazione possono acconsentire all'accesso ai loro dati da parte delle app, il che significa che le “concessioni” di consenso, e le concessioni di consenso potenzialmente eccessive, potrebbero essere trascurate.

Scenario di esempio: Uno sviluppatore o un fornitore crea un'applicazione che ha bisogno di informazioni dal tenant affinché l'applicazione funzioni nel modo previsto. Crea quindi una App Registration. La registrazione dell'applicazione fornisce l'URL per accedere all'applicazione e le autorizzazioni necessarie. Quando un utente desidera utilizzare l'applicazione, accede all'URL e gli viene richiesto di fornire il consenso, ossia di permettere all'applicazione di accedere ai dati.

Bisogna fare molta attenzione perchè basta un solo account utente compromesso per dare il consenso a un'applicazione rogue. Modelli comuni di attacchi alla catena di fornitura includono il bersagliare i fornitori di app multi-tenant per sottrarre dati dalle organizzazioni su larga scala con un impatto senza precedenti, come è successo per l'attacco a SolarWinds.

C'è una differenza tra il consenso di un amministratore e il consenso di altri. Quando viene fornito il consenso dell'amministratore, l'applicazione, il servizio e/o il sistema sono disponibili per tutti i membri dell'organizzazione e le autorizzazioni possono essere concesse al di là della portata di un utente. Un amministratore potrebbe acconsentire all'autorizzazione User.Read.All, invece che all'autorizzazione User.Read API.

Il consenso dell'utente si limita a concedere l'autorizzazione all'applicazione, al servizio e/o al sistema per l'ambito dell'utente che ha dato il consenso.

Ruoli Applicazione e Ambito

Gli App Roles vengono creati nell'App Registration e sono specifici per quell'app. Sono utilizzati per assegnare permessi all'interno della tua app.

Ad esempio, potresti creare un ruolo dell'app chiamato "Full Admin" che potrebbe fare tutto all'interno della tua app. La tua app deve avere una logica per leggere il token, leggere i ruoli al suo interno e concedere i permessi appropriati all'interno dell'app.

Quando crei il ruolo dell'app, puoi decidere che tipi di oggetti possono essere assegnati al ruolo dell'app. Le opzioni sono: Utenti/Gruppi, Applicazioni o Entrambi.

Gli Scopes sono utili quando le app devono comunicare con altre app utilizzando Permessi Delegati. Questo significa che se un utente accede a App1 e App1 deve comunicare con App2, lo farà per conto dell'utente. In altre parole, App1 comunicherà con App2 utilizzando le credenziali dell'utente che ha effettuato l'accesso a App1.

Se devi aggiornare gli Scopes nel manifesto della registrazione dell'app, li troverai nella sezione 'oauth2Permissions'.

Riferimenti

• https://learn.microsoft.com/en-us/entra/identity-platform/v2-overview
• https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols
• https://learn.microsoft.com/en-us/graph/overview
• https://learn.microsoft.com/en-us/entra/identity-platform/permissions-consent-overview
• https://learn.microsoft.com/en-us/entra/identity-platform/application-model
• https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals
• https://learn.microsoft.com/en-us/entra/identity-platform/single-and-multi-tenant-apps