Chiamare un'API da un'altra API
Come si fa, in qualità di sviluppatore, a garantire Zero Trust quando si dispone di un'API che deve chiamare un'altra API? Questo articolo illustra come sviluppare in modo sicuro l'applicazione quando lavora per conto di un utente.
Quando un utente guida l'interfaccia utente di un'app, l'app potrebbe usare un'autorizzazione delegata in modo che l'API conosca quale utente per conto dell'app funziona. Esamina le attestazioni dell'oggetto (sub) o dell'ID oggetto (oid) e dell'ID tenant (tid) nel token di accesso fornito dall'app quando chiama l'API. L'API non si basa sull'app non attendibile, che è solo una chiamata proveniente da un punto qualsiasi della rete. Convalidare invece il token per assicurarsi che l'API funzioni solo per conto dell'utente dell'app verificato dall'ID Microsoft Entra.
Quando un'API (si fa riferimento a essa come API originale) chiama un'altra, è fondamentale che l'API che viene chiamata (che si fa riferimento all'API Downstream) segua il processo di convalida descritto in precedenza. L'API Downstream non può basarsi su un'origine di rete non attendibile. Deve ottenere l'identità utente da un token di accesso convalidato correttamente.
Se l'API Downstream non segue il processo di convalida corretto, l'API Downstream deve basarsi sull'API originale per fornire l'identità dell'utente in un altro modo. L'API Downstream potrebbe usare erroneamente un'autorizzazione dell'applicazione per eseguire l'operazione. L'API originale diventa quindi l'unica autorità su cui gli utenti potrebbero ottenere i risultati rispetto all'API Downstream. L'API originale potrebbe intenzionalmente (o involontariamente) consentire a un utente di eseguire un'attività che l'utente non poteva altrimenti eseguire. Ad esempio, un utente può modificare i dettagli di un altro utente o leggere e aggiornare i documenti a cui l'utente non ha l'autorizzazione per accedere. La convalida non corretta può causare gravi problemi di sicurezza.
Per una maggiore sicurezza, l'API originale acquisisce un token di accesso con autorizzazione delegata per fornire all'API Downstream quando l'API originale effettua la chiamata. Verrà ora illustrato come funziona.
L'app client acquisisce il token di accesso per chiamare l'API originale
Il diagramma seguente illustra l'app client e l'API originale.
L'applicazione client ha acquisito un token di accesso con autorizzazione delegata (indicato dalla forma del pentagono con l'etichetta "A") all'API originale. Il token di accesso alle autorizzazioni delegate consente di lavorare per conto dell'utente per chiamare l'API originale che richiede l'autorizzazione.
L'app client fornisce il token di accesso all'API originale
L'animazione seguente mostra l'app client che concede il token di accesso all'API originale. L'API originale convalida e controlla completamente il token di accesso per determinare l'identità dell'utente dell'app client.
L'API originale esegue la convalida e l'imposizione dei token
L'animazione successiva mostra che, dopo che l'app client concede il token di accesso all'API originale, l'API originale esegue la convalida e l'imposizione dei token. Se tutto è valido, l'API procede e servizi la richiesta per l'app client.
L'API originale non può usare il token di accesso per chiamare l'API Downstream
L'animazione seguente mostra che l'API originale vuole ora chiamare un'API Downstream. Tuttavia, l'API originale non può usare il token di accesso per chiamare l'API Downstream.
L'API originale torna a Microsoft Entra ID
Nell'animazione seguente, l'API originale deve tornare a Microsoft Entra ID. Richiede un token di accesso per chiamare l'API Downstream per conto dell'utente.
L'animazione successiva mostra l'API originale che fornisce il token ricevuto dall'API originale dall'app client e dalle credenziali client dell'API originale.
Microsoft Entra ID verifica la presenza di elementi come il consenso o l'imposizione dell'accesso condizionale. Potrebbe essere necessario tornare al client chiamante e fornire un motivo per cui non è possibile ottenere il token. In genere si usa un processo di verifica delle attestazioni per tornare all'applicazione chiamante con informazioni relative al consenso non ricevuto, ad esempio in relazione ai criteri di accesso condizionale.
Microsoft Entra ID esegue controlli
Nell'animazione seguente, Microsoft Entra ID esegue i controlli. Se tutto va bene, Microsoft Entra ID rilascia un token di accesso all'API originale per chiamare l'API Downstream per conto dell'utente.
L'API originale ha un contesto utente con flusso On-Behalf-Of
L'animazione seguente illustra il processo OBO (On-Behalf-Of Flow ) che consente a un'API di continuare ad avere il contesto utente mentre chiama l'API Downstream.
L'API originale chiama l'API Downstream
Nell'animazione successiva viene chiamata l'API Downstream. Il token ricevuto dall'API Downstream ha l'attestazione di destinatari (aud) appropriata che indica l'API Downstream.
Il token include gli ambiti per il consenso concesso e l'identità utente dell'app originale. L'API Downstream può implementare correttamente autorizzazioni valide per garantire che l'utente identificato disponga dell'autorizzazione per eseguire l'attività richiesta. Si vuole usare per conto del flusso per acquisire i token per un'API per chiamare un'altra API per assicurarsi che il contesto utente passi a tutte le API Downstream.
Opzione migliore: l'API originale esegue il flusso On-Behalf-Of
Questa ultima animazione mostra che l'opzione migliore è che l'API originale esegua il flusso On-Behalf-Of (OBO). Se l'API Downstream riceve il token corretto, può rispondere correttamente.
Quando un'API agisce per conto di un utente e deve chiamare un'altra API, l'API deve usare OBO per acquisire un token di accesso con autorizzazione delegata per chiamare l'API Downstream per conto dell'utente. Le API non devono mai usare le autorizzazioni dell'applicazione per chiamare le API Downstream quando l'API agisce per conto di un utente.
Passaggi successivi
- I flussi di autenticazione di Microsoft Identity Platform e gli scenari di app descrivono i flussi di autenticazione e gli scenari di applicazione in cui vengono usati.
- Protezione API descrive le procedure consigliate per proteggere l'API tramite la registrazione, la definizione di autorizzazioni e il consenso e l'applicazione dell'accesso per raggiungere gli obiettivi zero trust.
- Un esempio di API protetta dal framework di consenso delle identità Microsoft consente di progettare strategie di autorizzazioni dell'applicazione con privilegi minimi per un'esperienza utente ottimale.
- Personalizzare i token descrive le informazioni che è possibile ricevere nei token di Microsoft Entra. Spiega come personalizzare i token per migliorare la flessibilità e il controllo aumentando al contempo la sicurezza senza attendibilità delle applicazioni con privilegi minimi.
- Il modulo Secure custom APIs with Microsoft Identity Learn (Proteggere le API personalizzate con Microsoft Identity Learn) illustra come proteggere un'API Web con l'identità Microsoft e come chiamarla da un'altra applicazione.
- Le procedure consigliate per la sicurezza per le proprietà dell'applicazione descrivono l'URI di reindirizzamento, i token di accesso (usati per i flussi impliciti), i certificati e i segreti, l'URI ID applicazione e la proprietà dell'applicazione.
- Le librerie di autenticazione di Microsoft Identity Platform descrivono il supporto di Microsoft Authentication Library per vari tipi di applicazione.
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per