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 del soggetto (sub) o l'ID oggetto (oid) e le attestazioni ID del tenant (tid) nel token di accesso fornito dall'app durante la chiamata all'API. L'API non dipende dall'app non fidata, che è solo una chiamata proveniente da un punto qualsiasi della rete. Convalida 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. 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. Successivamente, l'API originale diventa l'unica autorità che determina quali risultati gli utenti possono ottenere rispetto all'API Downstream. L'API originale può intenzionalmente (o involontariamente) consentire a un utente di eseguire un'attività che l'utente non può 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.

1. L'app client acquisisce il token di accesso per chiamare l'API originale. L'applicazione client acquisisce un token di accesso con autorizzazione delegata 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.
2. L'app client fornisce il token di accesso all'API originale. L'app client fornisce 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.
3. L'API originale esegue la convalida e l'imposizione dei token. 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.
4. L'API originale non può usare il token di accesso per chiamare l'API Downstream. L'API originale vuole chiamare un'API Downstream. Tuttavia, l'API originale non può usare il token di accesso per chiamare l'API Downstream.
5. L'API originale torna a Microsoft Entra ID. L'API originale deve tornare a Microsoft Entra ID. Richiede un token di accesso per chiamare l'API Downstream per conto dell'utente. L'API originale fornisce il token che ha ricevuto dall'app client e le credenziali client proprie dell'API originale.
6. Microsoft Entra ID esegue controlli. 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. Se tutto va bene, Microsoft Entra ID rilascia un token di accesso all'API originale per chiamare l'API Downstream per conto dell'utente.
7. L'API originale include il contesto dell'utente nel flusso On-Behalf-Of. Il processo on-Behalf-Of flow (OBO) consente a un'API di continuare ad avere il contesto utente mentre chiama l'API Downstream.
8. L'API iniziale chiama la Downstream API. Chiama 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

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 Zero Trust dell'applicazione 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, 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.