Applicazioni client pubbliche e riservate

Microsoft Authentication Library (MSAL) definisce due tipi di client; client pubblici e client riservati. Un client è un'entità software con un identificatore univoco assegnato da un provider di identità. I tipi di client si distinguono per la possibilità di eseguire l'autenticazione in modo sicuro con il server di autorizzazione e di conservare informazioni sensibili e di prova dell'identità in modo che non possano essere accessibili o noti a un utente nell'ambito dell'accesso.

App client pubbliche	App client riservate
App desktop	App Web
API senza browser	Web API
App per dispositivi mobili	Servizio/daemon

Autorizzazione client pubblica e riservata del client

Quando si esamina la natura pubblica o riservata di un determinato client, si sta valutando la possibilità di tale client di dimostrare la propria identità al server di autorizzazione. Questo è importante perché il server di autorizzazione deve essere in grado di considerare attendibile l'identità del client per rilasciare token di accesso.

• Applicazioni client pubbliche eseguite su dispositivi, ad esempio desktop, API senza browser, app per dispositivi mobili o sul lato client. Non possono essere considerati attendibili per mantenere in modo sicuro i segreti dell'applicazione, quindi possono accedere solo alle API Web per conto dell'utente. Ogni volta che l'origine o il bytecode compilato di una determinata app viene trasmesso ovunque possa essere letto, disassemblato o controllato da parti non attendibili, si tratta di un client pubblico. Inoltre, poiché supportano solo i flussi client pubblici e non possono contenere segreti in fase di configurazione, non possono avere segreti client.

• Le applicazioni client riservate eseguite su server come le app Web, le app API Web o le app di servizio/daemon. Sono considerati di difficile accesso da parte degli utenti o utenti malintenzionati e pertanto possono contenere in modo adeguato i segreti in fase di configurazione per asserire la prova della propria identità. L'ID client viene esposto tramite il Web browser, ma il segreto viene passato solo nel backchannel e non viene mai esposto direttamente.

Quando abilitare l'abilitazione di un flusso client pubblico nella registrazione dell'app?

Dopo aver determinato il tipo di applicazione client che si sta creando, è possibile decidere se abilitare il flusso client pubblico nella registrazione dell'app. Per impostazione predefinita, consentire il flusso client pubblico nella registrazione dell'app deve essere disabilitato a meno che l'utente o lo sviluppatore non stia creando un'applicazione client pubblica e usando il protocollo o le funzionalità di autorizzazione OAuth seguenti:

Segreti e loro importanza nella dimostrazione dell'identità

Di seguito sono riportati alcuni esempi di come un client può dimostrare la propria identità al server di autorizzazione:

• Identità gestite per le risorse di Azure: per scenari di autenticazione solo app, sviluppatori di applicazioni e servizi basati su Azure hanno la possibilità di eseguire l'offload della gestione, della rotazione e della protezione dei segreti nella piattaforma stessa. Con le identità gestite, le identità vengono fornite ed eliminate con le risorse di Azure e nessuno, incluso l'amministratore globale, può accedere alle credenziali sottostanti. Usando le identità gestite, è possibile evitare il rischio di perdita di segreti e consentire al provider di gestire automaticamente la sicurezza.
• ID client e segreto : in questo modello, una coppia di valori viene generata dal server di autorizzazione durante la registrazione di un client. L'ID client è un valore pubblico che identifica l'applicazione, mentre il segreto client è un valore riservato usato per dimostrare l'identità dell'applicazione.
• La dimostrazione del possesso di un certificato – Public Key Infrastructure (PKI), che include standard come X.509, è la tecnologia fondamentale che consente la comunicazione sicura su Internet e costituisce la spina dorsale della privacy internet. L'infrastruttura a chiave pubblica viene usata per rilasciare certificati digitali che verificano l'identità delle parti coinvolte nella comunicazione online ed è la tecnologia sottostante che supporta protocolli come HTTPS, ampiamente usato per proteggere il traffico Web. Analogamente, i certificati possono essere usati per proteggere la comunicazione da servizio a servizio (S2S) in Azure abilitando l'autenticazione reciproca tra i servizi. Ciò implica che ogni servizio presenti un certificato all'altro come mezzo per dimostrare la propria identità.
• Presentazione di un'asserzione firmata: usata nella federazione delle identità del carico di lavoro, le asserzioni firmate consentono lo scambio di un token di provider di identità di terze parti attendibile con Microsoft Identity Platform per ottenere i token di accesso per chiamare le risorse protette di Microsoft Entra. La federazione delle identità del carico di lavoro può essere usata per abilitare diversi scenari di federazione, tra cui servizio Azure Kubernetes, Amazon Web Services EKS, GitHub Actions e altro ancora.

Quando la dimostrazione dell'identità del cliente è importante?

La dimostrazione dell'identità client è importante quando è necessario verificare sia l'autenticità che l'autorizzazione di un'applicazione client prima di concedere l'accesso a dati o risorse sensibili. Alcuni esempi includono:

• Controllo dell'accesso all'API : se si ha un'API a consumo (ad esempio per la fatturazione) o si espongono dati o risorse sensibili, verificare l'identità del client prima di concedere l'accesso. Ad esempio, questo aspetto è importante quando si garantisce che solo le applicazioni autorizzate abbiano accesso all'API e che il cliente corretto venga fatturato per l'utilizzo delle API a consumo.
• Protezione degli utenti dalla rappresentazione dell'app: se si dispone di un'applicazione distribuita con il servizio, ad esempio un'app Web guidata da back-end, che accede a dati o servizi sensibili, usando segreti client per proteggere le risorse usate da tale applicazione può impedire agli attori malintenzionati di rappresentare un client legittimo per individuare utenti e esfiltrare dati o accessi impropri.
• Comunicazione da sito a sito: se si dispone di più servizi back-end (ad esempio api downstream) che devono comunicare tra loro, è possibile verificare l'identità di ogni servizio per assicurarsi che siano autorizzati ad accedere solo alle risorse necessarie per eseguire la loro funzione.

In generale, la dimostrazione dell'identità client è importante quando è necessario autenticare e autorizzare un client indipendente da o oltre a un utente.

Client riservati: procedure consigliate per la gestione dei segreti

Usare le identità gestite per semplificare la distribuzione e la sicurezza : le identità gestite forniscono un'identità gestita automaticamente in Microsoft Entra ID per le applicazioni da usare per la connessione alle risorse che supportano l'autenticazione di Microsoft Entra. Le applicazioni possono usare le identità gestite per ottenere token solo app di Microsoft Entra ID senza dover gestire le credenziali. Ciò può rimuovere molte delle complessità associate alla gestione dei segreti, aumentando al contempo la sicurezza e la resilienza. Se si usano identità gestite, la maggior parte dei casi, se non tutte le procedure consigliate seguenti sono già state prese in considerazione per l'utente.

Usare l'archiviazione sicura: archiviare i segreti client in un percorso sicuro, ad esempio Key Vault o un file di configurazione crittografato. Evitare di archiviare i segreti client in testo non crittografato o come file archiviati nei sistemi di controllo della versione.

Limitare l'accesso: limitare l'accesso ai segreti client solo al personale autorizzato. Usare il controllo degli accessi in base al ruolo per limitare l'accesso ai segreti client solo a coloro che ne hanno bisogno per svolgere le proprie mansioni operative.

Ruotare i segreti client: la rotazione dei segreti client in base alle esigenze o pianificate può ridurre al minimo il rischio di utilizzo di un segreto compromesso per ottenere l'accesso non autorizzato. Se applicato, l'intervallo di tempo durante il quale una chiave viene suggerita per rimanere in uso è influenzata dalla forza dell'algoritmo di crittografia usato e/o dalla conformità agli standard o alle procedure di conformità alle normative.

Usare segreti lunghi e crittografia avanzata: strettamente correlato al punto precedente, l'uso di algoritmi di crittografia avanzata per i dati in transito (in transito) e inattivi (su disco) consente di garantire che i segreti ad entropia elevata rimangano improbabili forzati. Gli algoritmi come AES-128 (o versione successiva) consentono di proteggere i dati inattivi, mentre RSA-2048 (o versione successiva) può contribuire a proteggere in modo efficiente i dati in transito. A causa della natura in continua evoluzione della cybersecurity, è sempre consigliabile consultare gli esperti di sicurezza e rivedere periodicamente la selezione dell'algoritmo.

Evitare segreti hardcoding: non impostare segreti client hardcoded nel codice sorgente. Evitare segreti nel codice sorgente può ridurre al minimo il valore degli attori malintenzionati che ottengono l'accesso al codice sorgente. Può anche impedire che tali segreti vengano accidentalmente inseriti in repository non sicuri o resi disponibili ai collaboratori del progetto che potrebbero avere accesso all'origine, ma non l'accesso segreto.

Monitorare i repository per i segreti persi: è un peccato che si verifichino errori di archiviazione quando si lavora con il codice sorgente. Gli hook di pre-commit Git sono un modo consigliato per evitare l'archiviazione accidentale, ma non è un sostituto del monitoraggio. Il monitoraggio automatizzato dei repository può identificare i segreti persi e, con un piano in atto per ruotare le credenziali compromesse, può contribuire a ridurre gli eventi imprevisti di sicurezza.

Monitorare l'attività sospetta: monitorare i log e i audit trail per le attività sospette correlate ai segreti client. Se possibile, usare gli avvisi automatizzati e i processi di risposta per notificare al personale e definire contingenze per attività insolite correlate ai segreti client.

Progettare le applicazioni tenendo presente la segretezza dei client: il modello di sicurezza è altrettanto forte quanto il collegamento più debole nella catena. Non inoltrare le credenziali di sicurezza o i token dai client riservati ai client pubblici, in quanto ciò potrebbe spostare i dati dei segreti client in un client pubblico, consentendo la rappresentazione del client riservato.

Usare librerie e SDK aggiornati da origini attendibili: Microsoft Identity Platform offre diversi SDK client e server e middleware progettati per migliorare la produttività mantenendo al tempo stesso la sicurezza delle applicazioni. Le librerie come Microsoft.Identity.Web semplificano l'aggiunta di autenticazione e autorizzazione alle app Web e alle API in Microsoft Identity Platform. Mantenere aggiornate le dipendenze consente di garantire che le applicazioni e i servizi traggano vantaggio dalle ultime innovazioni e aggiornamenti della sicurezza.

Confronto tra i tipi di client e le relative funzionalità

Di seguito sono riportate alcune analogie e differenze tra le app client pubbliche e riservate:

• Entrambi i tipi di app mantengono una cache dei token utente e possono acquisire automaticamente un token (quando il token è presente nella cache). Le app client riservate hanno anche una cache di token dell'app per i token acquisiti dall'app stessa.
• Entrambi i tipi di app possono gestire gli account utente e ottenere un account dalla cache dei token utente, ottenere un account dal relativo identificatore o rimuovere un account.
• In MSAL le app client pubbliche hanno quattro modi per acquisire un token tramite flussi di autenticazione separati. Le app client riservate hanno solo tre modi per acquisire un token e un modo per calcolare l'URL dell'endpoint di autorizzazione del provider di identità. L'ID client viene passato una volta alla costruzione dell'applicazione e non deve essere passato di nuovo quando l'app acquisisce un token. Per altre informazioni, vedere Acquisizione di token.

I client pubblici sono utili per abilitare l'accesso delegato dall'utente alle risorse protette, ma non sono in grado di dimostrare la propria identità dell'applicazione. I client riservati, d'altra parte, possono eseguire sia l'autenticazione dell'utente che l'autorizzazione e l'autorizzazione dell'applicazione e devono essere compilati con sicurezza per assicurarsi che i segreti non vengano condivisi con client pubblici o altre terze parti.

In alcuni casi, ad esempio la comunicazione da sito a sito, l'infrastruttura come le identità gestite contribuisce notevolmente a semplificare lo sviluppo e la distribuzione dei servizi e rimuove gran parte della complessità in genere associata alla gestione dei segreti. Quando non è possibile usare le identità gestite, è importante disporre di criteri, misure preventive e contingenze per proteggere i segreti e rispondere agli eventi imprevisti di sicurezza correlati.

Vedi anche

Per altre informazioni sulla configurazione e la creazione di istanze dell'applicazione, vedere:

• Opzioni di configurazione dell'applicazione client
• Creazione di istanze di applicazioni client tramite MSAL.NET
• Creazione di istanze di applicazioni client tramite MSAL.js