Condividi tramite

Autenticazione e autorizzazione per le API in Gestione API di Azure

  • Articolo

SI APPLICA A: Tutti i livelli di Gestione API

Questo articolo offre un'introduzione a un set completo e flessibile di funzionalità di Gestione API che consente di proteggere l'accesso degli utenti alle API gestite.

L'autenticazione e l'autorizzazione delle API in Gestione API comportano la protezione della comunicazione end-to-end delle app client al gateway di Gestione API e tramite le API back-end. In molti ambienti dei clienti, OAuth 2.0 è il protocollo di autorizzazione API preferito. Gestione API supporta l'autorizzazione OAuth 2.0 tra il client e il gateway di Gestione API, tra il gateway e l'API back-end o in modo indipendente.

Diagramma che mostra i punti di interazione per la protezione delle API.

Gestione API supporta altri meccanismi di autenticazione e autorizzazione lato client e lato servizio che integrano OAuth 2.0 o che sono utili quando l'autorizzazione OAuth 2.0 per le API non è possibile. Il modo in cui si sceglie tra queste opzioni dipende dalla maturità dell'ambiente API dell'organizzazione, dai requisiti di sicurezza e conformità e dall'approccio dell'organizzazione per attenuare le minacce API comuni.

Importante

La protezione dell'accesso degli utenti alle API è una delle molte considerazioni per proteggere l'ambiente di Gestione API. Per altre informazioni, vedere Baseline di sicurezza di Azure per Gestione API.

Nota

Altri componenti di Gestione API hanno meccanismi separati per proteggere e limitare l'accesso degli utenti:

  • Per gestire l'istanza di Gestione API tramite il piano di controllo di Azure, Gestione API si basa su Microsoft Entra ID e controllo degli accessi in base al ruolo di Azure.
  • Il portale per sviluppatori di Gestione API supporta diverse opzioni per facilitare l'iscrizione e l'accesso sicuri degli utenti.

Confronto tra autenticazione e autorizzazione

Ecco una breve spiegazione dell'autenticazione e autorizzazione nel contesto dell'accesso alle API:

  • Autenticazione - Il processo di verifica dell'identità di un utente o di un'app che accede all'API. L'autenticazione può essere eseguita tramite credenziali come nome utente e password, un certificato, o tramite Single Sign-On (SSO) o altri metodi.

  • Autorizzazione - Il processo che determina se un utente o un'app dispone dell’autorizzazione per accedere a una determinata API, spesso tramite un protocollo basato su token come OAuth 2.0.

Nota

Per integrare l'autenticazione e autorizzazione, l'accesso alle API deve essere protetto anche tramite TLS per proteggere le credenziali o i token usati per l'autenticazione o autorizzazione.

Concetti relativi a OAuth 2.0

OAuth 2.0 è un framework di autorizzazione standard ampiamente usato per proteggere l'accesso alle risorse, ad esempio le API Web. OAuth 2.0 limita le azioni che un'app client può eseguire sulle risorse per conto dell'utente, senza condividere mai le credenziali dell'utente. Anche se OAuth 2.0 non è un protocollo di autenticazione, viene spesso usato con OpenID Connect (OIDC), che estende OAuth 2.0 fornendo l'autenticazione utente e la funzionalità SSO.

Flusso OAuth

Cosa accade quando un'app client chiama un'API con una richiesta protetta tramite TLS e OAuth 2.0? Di seguito è riportato un flusso di esempio abbreviato:

  • Il client (l'app chiamante o il bearer) esegue l'autenticazione usando le credenziali di un provider di identità.

  • Il client ottiene un token di accesso limitato al tempo (un token Web JSON o JWT) dal server di autorizzazione del provider di identità.

    Il provider di identità (ad esempio, Microsoft Entra ID) è l'autorità di certificazione del token e il token include un'attestazione del gruppo di destinatari che autorizza l'accesso a un server di risorse, ad esempio a un'API back-end o al gateway di Gestione API stesso.

  • Il client chiama l'API e presenta il token di accesso, ad esempio in un'intestazione di autorizzazione.

  • Il server di risorse convalida il token di accesso. La convalida è un processo complesso che include un controllo che l'autorità emittente e le attestazioni del gruppo di destinatari contengono valori previsti.

  • In base ai criteri di convalida dei token, viene quindi concesso l'accesso alle risorse dell'API back-end.

A seconda del tipo di app client e degli scenari, sono necessari dei flussi di autorizzazione diversi per richiedere e gestire i token. Ad esempio, il flusso del codice di autorizzazione e il tipo di concessione vengono comunemente usati nelle app che chiamano API Web. Altre informazioni sui flussi OAuth e sugli scenari di applicazione in Microsoft Entra ID.

Scenari di autorizzazione OAuth 2.0 in Gestione API

Scenario 1 - L'app client autorizza direttamente al back-end

Uno scenario di autorizzazione comune è quando l'applicazione chiamante richiede l'accesso diretto all'API back-end e presenta un token OAuth 2.0 in un'intestazione di autorizzazione al gateway. Gestione API di Azure funge quindi da proxy "trasparente" tra il chiamante e l'API back-end e passa il token senza modifiche al back-end. L'ambito del token di accesso è tra l'applicazione chiamante e l'API back-end.

L'immagine seguente mostra un esempio in cui Microsoft Entra ID è il provider di autorizzazioni. L'app client potrebbe essere un'applicazione a pagina singola.

Diagramma che mostra la comunicazione OAuth in cui il gruppo di destinatari è il back-end.

Anche se il token di accesso inviato insieme alla richiesta HTTP è destinato all'API back-end, Gestione API consente comunque un approccio di difesa approfondito. Ad esempio, configurare i criteri per convalidare il token JWT, rifiutare le richieste che arrivano senza un token o un token non valido per l'API back-end prevista. È anche possibile configurare Gestione API per controllare altre attestazioni di interesse estratte dal token.

Nota

Se si protegge un'API esposta tramite Gestione API di Azure con OAuth 2.0 in questo modo, è possibile configurare Gestione API per generare un token valido per scopi di test per conto di un utente della console di test del portale di Azure o del portale per sviluppatori. È necessario aggiungere un server OAuth 2.0 all'istanza di Gestione API e abilitare le impostazioni di autorizzazione OAuth 2.0 nell'API. Per altre informazioni, vedere Come autorizzare la console di test del portale per sviluppatori configurando l'autorizzazione utente OAuth 2.0.

Esempio:

Suggerimento

Nel caso speciale in cui l'accesso all'API è protetto tramite Microsoft Entra ID, è possibile configurare i criteri validate-azure-ad-token per la convalida dei token.

Scenario 2 : l'app client autorizza Gestione API

In questo scenario, il servizio Gestione API agisce per conto dell'API e l'applicazione chiamante richiede l'accesso all'istanza di Gestione API. L'ambito del token di accesso è tra l'applicazione chiamante e il gateway di Gestione API. In Gestione API configurare un criterio (validate-jwt o validate-azure-ad-token) per convalidare il token prima che il gateway passi la richiesta al back-end. Un meccanismo separato protegge in genere la connessione tra il gateway e l'API back-end.

Nell'esempio seguente, Microsoft Entra ID è di nuovo il provider di autorizzazione e l'autenticazione TLS reciproca (mTLS) protegge la connessione tra il gateway e il back-end.

Diagramma che mostra la comunicazione OAuth in cui il gruppo di destinatari è il gateway Gestione API.

Ci sono diversi motivi per farlo. Ad esempio:

  • Il back-end è un'API legacy che non può essere aggiornata per supportare OAuth

    Gestione API deve prima essere configurata per convalidare il token (verificando almeno le attestazioni dell'autorità emittente e del gruppo di destinatari). Dopo la convalida, usare una delle diverse opzioni disponibili per proteggere le connessioni successive da Gestione API, ad esempio l'autenticazione reciproca TLS (mTLS). Vedere Opzioni lato servizio, più avanti in questo articolo.

  • Il contesto richiesto dal backend non può essere stabilito dal chiamante

    Dopo che Gestione API ha convalidato correttamente il token ricevuto dal chiamante, deve quindi ottenere un token di accesso per l'API back-end usando il proprio contesto o il contesto derivato dall'applicazione chiamante. Questo scenario può essere eseguito usando:

    • Criteri personalizzati, ad esempio send-request, per ottenere un token di accesso successivo valido per l'API back-end da un provider di identità configurato.

    • Identità dell'istanza di Gestione API: passando il token dall'identità gestita assegnata dal sistema o assegnata dall'utente della risorsa di Gestione API all'API back-end.

  • L'organizzazione vuole adottare un approccio di autorizzazione standardizzato

    Indipendentemente dai meccanismi di autenticazione e autorizzazione nei back-end dell'API, le organizzazioni possono scegliere di convergere su OAuth 2.0 per un approccio di autorizzazione standardizzato nel front-end. Il gateway di Gestione API può abilitare una configurazione coerente delle autorizzazioni e un'esperienza comune per i consumer di API man mano che i back-end dell'organizzazione si evolvono.

Scenario 3: Gestione API autorizza il back-end

Con le connessioni gestite (in precedenza denominate autorizzazioni), si usa Gestione credenziali in Gestione API per autorizzare l'accesso a uno o più servizi SaaS o back-end, ad esempio LinkedIn, GitHub o altri back-end compatibili con OAuth 2.0. In questo scenario, un utente o un'app client effettua una richiesta al gateway di Gestione API, con l'accesso al gateway controllato usando un provider di identità o altre opzioni lato client. Quindi, tramite la configurazione dei criteri, l'utente o l'app client delega l'autenticazione back-end e l'autorizzazione a Gestione API.

Nell'esempio seguente viene usata una chiave di sottoscrizione tra il client e il gateway e GitHub è il provider di credenziali per l'API back-end.

Diagramma che mostra l'autorizzazione al servizio SaaS back-end usando una connessione gestita in Gestione credenziali.

Con una connessione a un provider di credenziali, Gestione API acquisisce e aggiorna i token per l'accesso API nel flusso OAuth 2.0. Le connessioni semplificano la gestione dei token in più scenari, ad esempio:

  • Un'app client potrebbe dover autorizzare più back-end SaaS a risolvere più campi usando i resolver GraphQL.
  • Gli utenti eseguono l'autenticazione a Gestione API tramite SSO dal provider di identità, ma autorizzano a un provider SaaS back-end (ad esempio LinkedIn) usando un account aziendale comune.
  • Un'app client (o bot) deve accedere alle risorse online protette dal back-end per conto di un utente autenticato (ad esempio, controllare i messaggi di posta elettronica o effettuare un ordine).

Esempi:

Altre opzioni per proteggere le API

Mentre l'autorizzazione è preferibile e OAuth 2.0 è diventato il metodo dominante per abilitare l'autorizzazione avanzata per le API, Gestione API fornisce diversi altri meccanismi per proteggere o limitare l'accesso tra client e gateway (lato client) o tra gateway e back-end (lato servizio). A seconda dei requisiti dell'organizzazione, questi possono essere usati per integrare OAuth 2.0. In alternativa, configurarli in modo indipendente se le applicazioni chiamanti o le API back-end sono legacy o non supportano ancora OAuth 2.0.

Opzioni lato client

Meccanismo Descrizione Considerazioni
mTLS Convalidare il certificato presentato dal client di connessione e controllare le proprietà del certificato rispetto a un certificato gestito in Gestione API Il certificato può essere archiviato in un insieme di credenziali delle chiavi.
ip-filter Filtrare le chiamate (consenti/nega) da indirizzi IP o intervalli di indirizzi IP specifici. Usare per limitare l'accesso a determinati utenti o organizzazioni o al traffico proveniente da servizi upstream.
Chiave di sottoscrizione Limitare l'accesso a una o più API in base a una sottoscrizione di Gestione API È consigliabile usare una chiave di sottoscrizione (API) oltre a un altro metodo di autenticazione o autorizzazione. Da sola, una chiave di sottoscrizione non è una forma avanzata di autenticazione, ma l'uso della chiave di sottoscrizione può essere utile in determinati scenari, ad esempio, per tenere traccia dell'utilizzo delle API dei singoli clienti o concedere l'accesso a prodotti API specifici.

Suggerimento

Per la difesa approfondita, è consigliabile distribuire un web application firewall upstream dell'istanza di Gestione API. Ad esempio, usare gateway applicazione di Azure o Frontdoor di Azure.

Opzioni lato servizio

Meccanismo Descrizione Considerazioni
Autenticazione identità gestita Eseguire l'autenticazione all'API back-end con un'identità gestita assegnata dal sistema o assegnata dall'utente. Consigliato per l'accesso con ambito a una risorsa back-end protetta ottenendo un token dall'ID Microsoft Entra.
Autenticazione del certificato Eseguire l'autenticazione all'API back-end usando un certificato client. Il certificato può essere archiviato nell'insieme di credenziali delle chiavi.
Autenticazione di base Eseguire l'autenticazione all'API back-end con nome utente e password passati tramite un'intestazione di autorizzazione. Sconsigliato se sono disponibili opzioni migliori.

Passaggi successivi