Introduzione a OAuth 2.0

Questa pagina si applica ad Apigee e ad Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Home page di OAuth: consulta la home page di OAuth per una panoramica di alto livello delle indicazioni su OAuth che forniamo.

Questo argomento offre una panoramica di base di OAuth 2.0 su Apigee.

Che cos'è OAuth 2.0?

Esistono molti libri, blog e siti dedicati a OAuth 2.0. Ti consigliamo vivamente di iniziare consultando la specifica OAuth 2.0 di IETF. Ecco la definizione di OAuth 2.0 tratta dalla specifica IETF di OAuth 2.0:

"Il framework di autorizzazione OAuth 2.0 consente a un'applicazione di terze parti di ottenere un accesso limitato a un servizio HTTP, per conto di un proprietario della risorsa orchestrando un'interazione di approvazione tra il proprietario della risorsa e il servizio HTTP, oppure consentendo all'applicazione di terze parti di ottenere l'accesso per proprio conto."

La cosa principale che devi sapere è che OAuth 2.0 consente alle app di ottenere un accesso limitato alle risorse protette di un utente (pensa al conto bancario o a qualsiasi altra informazioni sensibili a cui un utente potrebbe voler accedere da un'app) senza che l'utente debba divulgare le proprie credenziali di accesso all'app.

Suggerimento: supponiamo che tu abbia trovato un'app che ti consente di accedere a più conti bancari. Forse l'app viene utilizzata per aiutarti con le tasse o per gestire il tuo budget. Hai tre conti bancari che vuoi gestire con l'app e hai un nome utente e una password diversi per ciascuno. Ora, per accedere ai tuoi conti bancari, l'app ha bisogno di queste credenziali sensibili. In pratica, stai fornendo queste informazioni sensibili all'app. Ritieni che l'app sia attendibile per la gestione delle tue password e dei tuoi nomi utente? Cosa succede se l'app viene compromessa? Ora devi ricordarti di modificare le credenziali bancarie per ogni account. Questo è il problema fondamentale che OAuth 2.0 risolve. Continua a leggere per scoprire come.

Il flusso OAuth 2.0

Di seguito è riportato il flusso generale per il framework di sicurezza OAuth 2.0. Questo flusso verrà illustrato in modo più dettagliato in questo argomento, a partire da un diagramma che spiega molto sul funzionamento di OAuth 2.0. Se non hai dimestichezza con i termini utilizzati in questo diagramma, leggi questa sezione per una rapida introduzione.

Termini da conoscere

• Client: chiamato anche app. Può essere un'app in esecuzione su un dispositivo mobile o un'app web tradizionale. L'app invia richieste al server delle risorse per gli asset protetti per conto del proprietario della risorsa. Il proprietario della risorsa deve concedere all'app l'autorizzazione per accedere alle risorse protette.
• Proprietario della risorsa: chiamato anche utente finale. In genere si tratta della persona (o di un'altra entità) in grado di concedere l'accesso a una risorsa protetta. Ad esempio, se un'app deve utilizzare i dati di uno dei tuoi siti di social media, tu sei il proprietario della risorsa, l'unica persona che può concedere all'app l'accesso ai tuoi dati.
• Server di risorse: immagina il server di risorse come un servizio come Facebook, Google o Twitter, un servizio RU sulla tua intranet o un servizio partner sulla tua extranet B2B. Apigee è un server di risorse ogni volta che è richiesta la convalida del token OAuth per elaborare le richieste API. Il server di risorse richiede un qualche tipo di autorizzazione prima di fornire risorse protette all'app.
• Server di autorizzazione: il server di autorizzazione è implementato in conformità con la specifica OAuth 2.0 ed è responsabile della convalida delle concessioni di autorizzazione e dell'emissione dei token di accesso che consentono all'app di accedere ai dati dell'utente sul server di risorse. Puoi configurare gli endpoint token su Apigee, nel qual caso Apigee assume il ruolo di server di autorizzazione.
• Concessione dell'autorizzazione: concede all'app l'autorizzazione per recuperare un token di accesso per conto dell'utente finale. OAuth 2.0 definisce quattro "grant type" specifici. Consulta Quali sono i grant type di OAuth 2.0.
• Token di accesso: una lunga stringa di caratteri che funge da credenziale utilizzata per accedere alle risorse protette. Consulta Che cos'è un token di accesso?.
• Risorsa protetta: dati di proprietà del proprietario della risorsa. Ad esempio, l'elenco contatti, i dati dell'account o altri dati sensibili dell'utente.

Il ruolo di Apigee

Puoi proteggere qualsiasi API con proxy tramite Apigee con OAuth 2.0. Apigee include un'implementazione del server di autorizzazione e, di conseguenza, può generare e convalidare i token di accesso. Gli sviluppatori iniziano registrando le proprie app con Apigee. Le app registrate possono richiedere token di accesso tramite una delle quattro interazioni di grant type.

Apigee fornisce una policy OAuthV2 multiforme che implementa i dettagli di ogni grant type, semplificando la configurazione di OAuth su Apigee. Ad esempio, puoi configurare una policy che riceve una richiesta di token di accesso, valuta tutte le credenziali richieste e restituisce un token di accesso se le credenziali sono valide.

Tieni presente che tutti i server di risorse chiamati dal proxy API sicuro devono essere protetti da un firewall (ovvero, le risorse non devono essere accessibili in alcun modo, ad eccezione del proxy API o di un'altra API ben protetta).

Nota: evita di esporre endpoint API non autenticati che emettono token di accesso, token OAuth, JWT o altri token di sicurezza o che restituiscono dati sensibili negli ambienti di produzione. Gli sviluppatori di proxy API sono responsabili della protezione di tutti gli endpoint API in Apigee utilizzando policy di sicurezza appropriate.

Quali sono i grant type di OAuth 2.0?

Pensa ai grant type come a percorsi o interazioni diversi che un'app può intraprendere per ottenere un token di accesso. Ogni grant type è adatto a uno o più casi d'uso e dovrai selezionare i grant type da utilizzare in base alle tue esigenze. In generale, ogni grant type presenta vantaggi e svantaggi e dovrai valutare i compromessi in base ai tuoi casi d'uso aziendali. Un aspetto importante da considerare è l'affidabilità delle app che accederanno ai tuoi dati. In genere, le app di terze parti sono meno affidabili di quelle sviluppate e utilizzate all'interno di un'azienda.

Apigee supporta i quattro principali grant type OAuth 2.0:

• authorization code (codice di autorizzazione): considerato il grant type più sicuro. Prima che il server di autorizzazione emetta un token di accesso, l'app deve ricevere un codice di autorizzazione dal server delle risorse. Hai visto questo flusso ogni volta che la tua app apre un browser alla pagina di accesso del server di risorse e ti invita ad accedere al tuo account effettivo (ad esempio Facebook o Twitter).

Se l'accesso va a buon fine, l'app riceverà un codice di autorizzazione che potrà utilizzare per negoziare un token di accesso con il server di autorizzazione. In genere, questo grant type viene utilizzato quando l'app si trova su un server anziché sul client. Questo grant type è considerato altamente sicuro perché l'app client non gestisce né vede mai il nome utente o la password dell'utente per il server di risorse (ad esempio, l'app non vede né gestisce mai le tue credenziali Twitter). Questo flusso del grant type è chiamato anche OAuth a tre vie.

• implicit: è considerata una versione semplificata del codice di autorizzazione. In genere, questo grant type viene utilizzato quando l'app si trova sul client. Ad esempio, il codice dell'app viene implementato in un browser utilizzando JavaScript o un altro linguaggio di scripting (anziché risiedere ed essere eseguito su un server web separato). In questo flusso di tipo di autorizzazione, il server di autorizzazione restituisce un token di accesso direttamente quando l'utente viene autenticato, anziché emettere prima un codice di autorizzazione. Le autorizzazioni implicite possono migliorare la reattività delle app in alcuni casi, ma questo vantaggio deve essere valutato rispetto alle possibili implicazioni di sicurezza, come descritto nella specifica IETF.
• Credenziali della password del proprietario della risorsa: in questo flusso, al client viene emesso un token di accesso quando il nome utente e la password dell'utente vengono convalidati dal server di autorizzazione. Questo flusso è consigliato per le applicazioni altamente attendibili. Un vantaggio di questo flusso rispetto, ad esempio, all'autenticazione di base, è che l'utente presenta il proprio nome utente/password una sola volta. Da quel momento in poi, viene utilizzato il token di accesso.
• client credentials: valuta la possibilità di utilizzare questo tipo di concessione per le situazioni in cui l'app client agisce per proprio conto. In altre parole, il client è anche il proprietario della risorsa. Questo grant type viene in genere utilizzato, ad esempio, quando l'app deve accedere a un servizio di archiviazione dei dati di backend. L'app deve utilizzare il servizio per svolgere il proprio lavoro e il servizio è altrimenti opaco per l'utente finale. Con questo grant type, un'app può ricevere un token di accesso presentando le proprie chiavi ID client e client secret al server di autorizzazione. Non sono necessari ulteriori passaggi. fornisce una soluzione di credenziali client pronta all'uso, facile da implementare per qualsiasi proxy API.

Che cos'è un token di accesso?

Un token di accesso è una lunga stringa di caratteri che funge da credenziale utilizzata per accedere alle risorse protette. I token delle risorse (chiamati anche token di connessione) vengono passati nelle intestazioni Authorization, in questo modo:

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

Il server delle risorse comprende che il token di accesso sostituisce credenziali come nome utente e password. Inoltre, i token di accesso possono essere emessi con restrizioni, in modo che, ad esempio, l'app possa leggere, ma non scrivere o eliminare dati sul server delle risorse. Tieni presente che un token di accesso può essere revocato se, ad esempio, l'app è compromessa. In questo caso, dovrai ottenere un nuovo token di accesso per continuare a utilizzare l'app, ma non dovrai modificare il nome utente o la password sul server delle risorse protette (ad esempio Facebook o Twitter).

In genere, i token di accesso hanno una scadenza (per motivi di sicurezza). Alcuni grant type consentono al server di autorizzazione di emettere un token di aggiornamento, che consente all'app di recuperare un nuovo token di accesso alla scadenza di quello precedente. Per maggiori dettagli sui token di accesso e sui token di aggiornamento, consulta la specifica IETF OAuth 2.0.

Accesso limitato tramite ambiti

Tramite il meccanismo degli ambiti, OAuth 2.0 può concedere a un'app un accesso limitato alle risorse protette. Ad esempio, un'app potrebbe avere accesso solo a risorse specifiche, potrebbe essere in grado di aggiornare le risorse o potrebbe avere solo l'accesso di sola lettura. Nei cosiddetti flussi OAuth a tre vie, l'utente in genere specifica il livello di accesso tramite una pagina di consenso (ad esempio, una pagina web in cui l'utente seleziona l'ambito con una casella di controllo o un altro meccanismo).

Registrazione di un'app

Tutti i client (app) devono registrarsi presso il server di autorizzazione OAuth 2.0 da cui intendono richiedere i token di accesso. Quando registri un'app, ricevi un set di chiavi. Una è una chiave pubblica chiamata identificatore client e l'altra è una chiave segreta chiamata client secret. Senza queste chiavi, un'app non può inviare richieste di codici di autorizzazione o token di accesso al server di autorizzazione. Tieni presente che, mentre la specifica OAuth IETF chiama queste chiavi ID client e client secret, la UI di Apigee le chiama ID consumatore e secret consumer. Sono equivalenti.

Riepilogo dei casi d'uso di OAuth 2.0

Il flusso del grant type OAuth 2.0 che scegli di implementare dipende dal tuo caso d'uso specifico, poiché alcuni grant type sono più sicuri di altri. La scelta dei grant type dipende dall'affidabilità dell'app client e richiede un'attenta valutazione, come descritto nella tabella seguente:

Caso d'uso	Attendibilità	Tipi di grant type di autorizzazione OAuth 2.0 suggeriti	Descrizione
B2B (extranet), intranet, altro	App attendibili, scritte da uno sviluppatore interno o da sviluppatori con un rapporto commerciale di fiducia con il provider dell'API. App che devono accedere alle risorse per proprio conto.	Credenziali client	In genere, l'app è anche il proprietario della risorsa Richiede l'ID client e le chiavi client secret Richiede la registrazione dell'app presso il fornitore di servizi
Siti intranet, portali	App attendibili scritte da sviluppatori interni o di terze parti attendibili. Un buon esempio è l'accesso al sito RU della tua azienda per effettuare selezioni assicurative, inviare recensioni o modificare informazioni personali.	Password Bias implicito	Richiede ID client e secret, oltre a nome utente e password Richiede la registrazione dell'app presso il fornitore di servizi
App disponibili pubblicamente	Le app non attendibili sono scritte da sviluppatori di terze parti che non hanno un rapporto commerciale di fiducia con il provider dell'API. Ad esempio, in genere non è consigliabile fidarsi degli sviluppatori che si registrano ai programmi API pubblici.	Codice di autorizzazione	Richiede all'utente di accedere al provider di risorse di terze parti (ad es. Twitter, Facebook) L'app non vede mai il nome utente e la password dell'utente Richiede la registrazione dell'app presso il fornitore di servizi
B2C	È coinvolto un singolo utente finale (utente mobile) e le credenziali utente sono memorizzate sul dispositivo mobile.	Bias implicito	Richiede che l'app sia registrata presso il fornitore di servizi. Le credenziali utente vengono memorizzate sul dispositivo su cui è in esecuzione l'app.

Sicurezza di OAuth 2.0 rispetto alla chiave API

La convalida della chiave API richiede che un'app invii una chiave ad Apigee. La chiave deve essere una chiave utente valida di un'app per sviluppatori Apigee associata al proxy API. Se per qualche motivo devi revocare l'autorizzazione di un'app client per effettuare chiamate a un proxy, devi revocare la chiave utente. Anche le app client che utilizzano questa chiave non potranno accedere al proxy API. D'altra parte, un token OAuth può essere revocato in qualsiasi momento senza revocare le chiavi dell'app. L'app può semplicemente richiedere un nuovo token per conto dell'utente e, se il token viene concesso, l'app può continuare a utilizzare il proxy API.

Un'altra differenza tra una chiave API e un token è che un token può includere attributi di metadati che puoi recuperare e utilizzare in un secondo momento. Ad esempio, puoi memorizzare l'ID dell'utente che effettua la chiamata API e utilizzarlo per personalizzare le chiamate al servizio di destinazione del backend.

Per informazioni dettagliate sulla convalida delle chiavi API, consulta Chiavi API. Per informazioni sull'utilizzo di attributi personalizzati con i token OAuth, consulta Personalizzazione di token e codici di autorizzazione.

Impatto dei tempi di scadenza e di eliminazione dei token sullo spazio di archiviazione su disco

Nota: questa sezione si applica solo ai clienti di Apigee Hybrid.

Quando generi un nuovo token OAuth con la policy OAuthV2, puoi impostare una data di scadenza per il token con l'attributo ExpiresIn. Per impostazione predefinita, i token vengono eliminati definitivamente dallo spazio di archiviazione tre giorni dopo la scadenza. Se imposti un tempo di scadenza elevato, ad esempio 48 ore, potresti notare un aumento imprevisto dell'utilizzo dello spazio su disco per Cassandra. Per evitare un utilizzo eccessivo dello spazio su disco, puoi impostare una scadenza più breve (consigliamo un'ora) e/o impostare una configurazione che riduca il ritardo di tre giorni dopo la scadenza.

I clienti di Apigee hybrid possono modificare il tempo di eliminazione predefinito impostando la seguente configurazione nel file degli override:

runtime:
  cwcAppend:
    "conf_keymanagement_oauth.access.token.purge.after.seconds": "SECONDS"

Dove SECONDS è il numero di secondi che Apigee attenderà per eliminare i token dopo la loro scadenza. Assicurati di includere questa stanza esattamente come scritta, incluse le virgolette.

Ad esempio, per impostare il tempo di eliminazione su un'ora dopo la scadenza:

runtime:
  cwcAppend:
    "conf_keymanagement_oauth.access.token.purge.after.seconds": "3600"

Risorse consigliate

Lettura

Consulta Scopri di più su OAuth 2.0.