Condividi tramite

Gestire i token per Zero Trust

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. In qualità di sviluppatore, questo articolo ti aiuta a integrare la sicurezza nelle tue applicazioni con i token ID, i token di accesso e i token di sicurezza che l'app può ricevere dalla piattaforma di identità di Microsoft.

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. Fornire 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 possono specificare condizioni di autenticazione, ad esempio MFA, dispositivi gestiti e posizioni corrette.

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

Usare le attestazioni di token nelle app

Usare le affermazioni nei token ID per migliorare l'esperienza utente all'interno dell'applicazione come chiavi in un database. Fornire l'accesso all'applicazione client. Il token ID è l'estensione principale che OpenID Connect (OIDC) apporta 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'affermazione audience (aud) è l'ID client della tua app. Accetta solo i token per l'API client ID.
  • L'identificativo 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 attributi e oid come chiave quando è necessario associare i dati all'utente. Usa questi valori di attestazione per riconnettere i tuoi dati all'ID dell'utente in Microsoft Entra ID.
  • L'attestazione sub è un valore non modificabile che identifica in modo univoco l'utente. Anche la dichiarazione del soggetto è univoca per la tua applicazione. Se si utilizza l'attestazione sub per associare i dati all'utente, non è possibile passare dai propri dati e connetterli 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 il campo openid insieme al formato e al contenuto del token ID. OIDC specifica questi ambiti:

  • Usare l'ambito openid per autenticare l'utente e aggiungere un attributo sub al token ID. Questi ambiti forniscono un ID utente che è univoco per l'app e l'utente e chiamano 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 gli scope openid, email e profile 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 il seguente ambito offline_access. Microsoft Identity Platform restituisce sempre offline_access 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 ripetere 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, assicurarsi che i token siano validi e non scaduti. L'attestazione del gruppo di destinatari (aud) deve corrispondere all'ID client. Assicurarsi che il token provenga da un'autorità di certificazione attendibile. Se si dispone di un'API multi-tenant, è possibile scegliere di filtrare in modo che solo tenant specifici possano chiamare l'API. Assicurati di far rispettare la durata del token. Controllare le attestazioni nbf (non prima) e exp (scadenza) per assicurarsi che l'ora corrente sia compresa nei valori di tali due attestazioni.

Non mirare a durate di sessione estremamente lunghe o brevi. Permettere alla durata del token ID concesso di determinare 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, ad esempio ASP.NET, consentono di impostare i timeout di sessione e cookie in base al tempo di scadenza del token di Microsoft Entra ID. Seguire il tempo di scadenza del token del provider di identità per assicurarsi che le sessioni dell'utente non siano mai più lunghe dei criteri definiti dal provider di identità.

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. Usa i token per tutta la durata della loro vita e memorizzali nella cache in modo appropriato. Se si richiede ripetutamente lo stesso token, il throttling fa sì che l'applicazione diventi meno reattiva. Se l'app abusa del rilascio dei token, il tempo necessario per rilasciare nuovi token all'app si allunga.

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 non riesce 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 del fornitore 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

  • Last updated on