Share via


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.

Diagramma che mostra l'app client con ID e token di accesso e l'API originale che richiede l'autorizzazione.

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.

Diagramma animato che mostra l'app client che fornisce un token di accesso all'API originale che richiede l'autorizzazione.

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.

Diagramma animato che mostra l'app client con token ID a sinistra che assegna il token di accesso all'API originale a destra.

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.

Diagramma animato che mostra l'app client che concede il token di accesso all'API originale. Authorization Required impedisce all'API originale di fornire il token all'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.

Diagramma animato che mostra l'app client che concede il token di accesso all'API originale che richiede la convalida da Microsoft Entra ID per chiamare l'API Downstream.

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.

Diagramma animato che mostra l'app client che concede il token di accesso all'API originale che riceve la convalida dall'ID Microsoft Entra per chiamare l'API Downstream.

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.

Diagramma animato che mostra l'API originale che concede il token di accesso all'API Downstream dopo la convalida con Microsoft Entra ID.

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.

Diagramma animato che mostra l'API originale che concede il token di accesso all'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.

Diagramma animato che mostra l'API Downstream che convalida il token di accesso dall'API originale.

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.

Diagramma animato che mostra l'API Downstream che riceve il token di accesso dall'API originale.

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