Condividi tramite

Gestire i token per Zero Trust

  • Articolo

Nello sviluppo di applicazioni Zero Trust è importante definire in modo specifico l'intenzione dell'applicazione e i relativi requisiti di accesso alle risorse. L'app deve richiedere solo l'accesso necessario per funzionare come previsto. Questo articolo illustra come sviluppatore la sicurezza nelle applicazioni con token ID, token di accesso e token di sicurezza che l'app può ricevere da Microsoft Identity Platform.

Assicurarsi che l'applicazione rispetti il principio Zero Trust dei privilegi minimi e impedisca l'utilizzo in modi che compromettano l'intenzione. Limitare l'accesso degli utenti con JUST-In-Time e Just-Enough-Access (JIT/JEA), criteri adattivi basati sui rischi e protezione dei dati. Separare le sezioni sensibili e potenti dell'app, fornendo solo l'accesso utente autorizzato a queste aree. Limitare gli utenti che possono usare l'applicazione e le funzionalità disponibili nell'app.

Creare privilegi minimi nel modo in cui l'applicazione gestisce i token ID ricevuti da Microsoft Identity Platform. Le informazioni nei token ID consentono di verificare che un utente sia l'utente che dichiara di essere. L'utente o l'organizzazione potrebbe specificare condizioni di autenticazione come la fornitura di un'autenticazione a più fattori, l'uso di un dispositivo gestito e la posizione corretta.

Semplificare la gestione delle autorizzazioni per l'app da parte dei clienti. Ridurre il sovraccarico di provisioning degli utenti e la necessità di processi manuali. Il provisioning utenti automatico consente agli amministratori IT di automatizzare la creazione, la manutenzione e la rimozione delle identità utente negli archivi delle identità di destinazione. I clienti possono basare le automazione sulle modifiche apportate a utenti e gruppi con provisioning delle app o provisioning basato sulle risorse umane in Microsoft Entra ID.

Usare le attestazioni di token nelle app

Usare le attestazioni nei token ID per l'esperienza utente all'interno dell'applicazione, come chiavi in un database e fornire l'accesso all'applicazione client. Il token ID è l'estensione principale eseguita da OpenID Connessione (OIDC) a OAuth 2.0. L'app può ricevere token ID insieme o invece di token di accesso.

Nel modello standard per l'autorizzazione del token di sicurezza, un token ID rilasciato consente all'applicazione di ricevere informazioni sull'utente. Non usare il token ID come processo di autorizzazione per accedere alle risorse. Il server di autorizzazione rilascia token ID che contengono attestazioni con informazioni utente che includono quanto segue.

  • L'attestazione audience (aud) è l'ID client dell'app. Accettare solo i token per l'ID client DELL'API.
  • L'attestazione tid è l'ID del tenant che ha emesso il token. L'attestazione oid è un valore non modificabile che identifica in modo univoco l'utente. Usare la combinazione univoca di tid attestazioni e oid come chiave quando è necessario associare i dati all'utente. È possibile usare questi valori di attestazione per connettere i dati all'ID dell'utente in Microsoft Entra ID.
  • L'attestazione sub è un valore non modificabile che identifica in modo univoco l'utente. Anche l'attestazione del soggetto è univoca per l'applicazione. Se si usa l'attestazione sub per associare i dati all'utente, non è possibile passare dai dati e connetterla a un utente in Microsoft Entra ID.

Le app possono usare l'ambito openid per richiedere un token ID da Microsoft Identity Platform. Lo standard OIDC regola l'ambito insieme al openid formato e al contenuto del token ID. OIDC specifica questi ambiti:

  • Usare l'ambito openid per accedere all'utente e aggiungere un'attestazione sub al token ID. Questi ambiti forniscono un ID utente univoco per l'app e l'utente e chiama l'endpoint UserInfo.
  • L'ambito email aggiunge un'attestazione email contenente l'indirizzo di posta elettronica dell'utente al token ID.
  • L'ambito profile aggiunge attestazioni con attributi di profilo di base dell'utente (nome, nome utente) al token ID.
  • L'ambito offline_access consente all'app di accedere ai dati utente anche quando l'utente non è presente.

Microsoft Authentication Library (MSAL) aggiunge sempre l'openid, la posta elettronica e profile gli ambiti a ogni richiesta di token. Di conseguenza, MSAL restituisce sempre un token ID e un token di accesso per ogni chiamata a AcquireTokenSilent o AcquireTokenInteractive. MSAL richiede sempre l'ambito offline_access . Microsoft Identity Platform restituisce offline_access sempre l'ambito anche quando l'app richiedente non specifica l'ambito offline_access .

Microsoft usa lo standard OAuth2 per rilasciare token di accesso. Lo standard OAuth2 indica che si riceve un token, ma non specifica il formato del token o ciò che deve trovarsi nel token. Quando l'applicazione deve accedere a una risorsa che microsoft Entra ID protegge, deve usare un ambito definito dalla risorsa.

Ad esempio, Microsoft Graph definisce l'ambito che autorizza l'applicazione User.Read ad accedere al profilo utente completo dell'utente corrente e al nome del tenant. Microsoft Graph definisce le autorizzazioni nell'intera gamma di funzionalità disponibili in tale API.

Dopo l'autorizzazione, Microsoft Identity Platform restituisce un token di accesso all'applicazione. Quando chiami la risorsa, l'app fornisce questo token come parte dell'intestazione di autorizzazione della richiesta HTTP all'API.

Gestire la durata dei token

Le applicazioni possono creare una sessione per un utente dopo il completamento dell'autenticazione con l'ID Microsoft Entra. La gestione delle sessioni utente determina la frequenza con cui un utente deve eseguire di nuovo l'autenticazione. Il suo ruolo nel mantenere un utente verificato in modo esplicito davanti all'app con il privilegio giusto e per la giusta quantità di tempo è fondamentale. La durata della sessione deve essere basata sull'attestazione exp nel token ID. L'attestazione exp è l'ora in cui scade il token ID e il tempo dopo il quale non è più possibile usare il token per autenticare l'utente.

Rispettare sempre la durata del token come specificato nella risposta del token per i token di accesso o l'attestazione exp nel token ID. Le condizioni che regolano la durata dei token possono includere la frequenza di accesso per un'azienda. L'applicazione non può configurare la durata del token. Non è possibile richiedere una durata del token.

In generale, i token devono essere validi e non scaduti. L'attestazione del pubblico (aud) deve corrispondere all'ID client. Assicurarsi che il token provena da un'autorità emittente attendibile. Se si dispone di un'API multi-tenant, è possibile scegliere di filtrare in modo che solo tenant specifici possano chiamare l'API. Assicurarsi di applicare la durata del token. Controllare le nbf attestazioni (non prima) e ( exp scadenza) per assicurarsi che l'ora corrente sia compresa nei valori delle due attestazioni.

Non mirare a durate di sessione estremamente lunghe o brevi. Consentire alla durata del token ID concesso di guidare questa decisione. Mantenere attive le sessioni dell'app oltre la validità del token viola le regole, i criteri e le preoccupazioni che hanno spinto un amministratore IT a impostare una durata di validità del token per impedire l'accesso non autorizzato. Le sessioni brevi riducono l'esperienza utente e non aumentano necessariamente il comportamento di sicurezza. I framework più diffusi come ASP.NET consentono di impostare timeout di sessione e cookie dall'ora di scadenza del token ID di Microsoft Entra ID. Dopo il tempo di scadenza del token del provider di identità, le sessioni dell'utente non saranno mai più lunghe dei criteri che il provider di identità impone.

Memorizzare nella cache e aggiornare i token

Ricordarsi di memorizzare nella cache i token in modo appropriato. MSAL memorizza automaticamente nella cache i token, ma i token hanno durate. Usare i token per tutta la durata della durata e memorizzarli nella cache in modo appropriato. Se si richiede ripetutamente lo stesso token, la limitazione fa sì che l'applicazione diventi meno reattiva. Se l'app esegue l'abuso del rilascio del token, il tempo necessario per l'emissione di nuovi token per l'app è più lungo.

Le librerie MSAL gestiscono i dettagli del protocollo OAuth2, inclusi i meccanismi di aggiornamento dei token. Se non si usa MSAL, assicurarsi che la libreria preferita usi in modo efficace i token di aggiornamento.

Quando il client acquisisce un token di accesso per accedere a una risorsa protetta, riceve un token di aggiornamento. Usare il token di aggiornamento per ottenere nuove coppie di token di accesso/aggiornamento dopo la scadenza del token di accesso corrente. Usare i token di aggiornamento per acquisire token di accesso aggiuntivi per altre risorse. I token di aggiornamento sono associati a una combinazione di utente e client (non a una risorsa o a un tenant). È possibile usare un token di aggiornamento per acquisire i token di accesso in qualsiasi combinazione di risorsa e tenant in cui l'app dispone delle autorizzazioni.

Gestire gli errori e i bug dei token

L'applicazione non deve mai tentare di convalidare, decodificare, esaminare, interpretare o esaminare il contenuto di un token di accesso. Queste operazioni sono strettamente responsabilità dell'API delle risorse. Se l'app tenta di esaminare il contenuto di un token di accesso, è molto probabile che l'applicazione si interrompa quando Microsoft Identity Platform rilascia token crittografati.

Raramente, una chiamata per recuperare un token può non riuscire a causa di problemi come rete, infrastruttura o errore o interruzione del servizio di autenticazione. Aumentare la resilienza dell'esperienza di autenticazione nell'applicazione se si verifica un errore di acquisizione di token seguendo queste procedure consigliate:

  • Memorizzare nella cache locale e proteggere i token con crittografia.
  • Non passare artefatti di sicurezza come token nei canali non sicuri.
  • Comprendere e agire sulle eccezioni e sulle risposte del servizio dal provider di identità.

Gli sviluppatori spesso hanno domande sull'analisi dei token interni per eseguire il debug di problemi, ad esempio la ricezione di un errore 401 dalla chiamata della risorsa. Poiché più token crittografati impediscono di cercare all'interno di un token di accesso, è necessario trovare alternative alla ricerca all'interno dei token di accesso. Per il debug, la risposta del token che contiene il token di accesso fornisce le informazioni necessarie.

Nel codice verificare la presenza di classi di errore anziché singoli casi di errore. Ad esempio, gestire l'interazione dell'utente necessaria anziché singoli errori quando il sistema non concede l'autorizzazione. Poiché si potrebbero perdere questi singoli casi, è preferibile verificare la presenza di un classificatore come l'interazione dell'utente anziché esaminare i singoli codici di errore.

Potrebbe essere necessario eseguire il fallback a AcquireTokenInteractive e fornire richieste di attestazioni richieste dalla AcquireTokenSilent chiamata. In questo modo si garantisce una gestione efficace della richiesta interattiva.

Passaggi successivi