Introduzione a OAuth 2.0

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Home page di OAuth: consulta la home page di OAuth per una visualizzazione di primo livello delle indicazioni di OAuth che forniamo.

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

Che cos'è OAuth 2.0?

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

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 conto proprio.

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

Il flusso OAuth 2.0

Di seguito è riportato il flusso generale per il framework di sicurezza OAuth 2.0. In questo argomento esamineremo questo flusso in modo più dettagliato, a partire da un diagramma che illustra molti aspetti del funzionamento di OAuth 2.0. Se non hai familiarità con i termini utilizzati in questo diagramma, leggi questa sezione per una breve introduzione.

Termini da conoscere

• Client:chiamato anche "l'app". Può essere un'app in esecuzione su un dispositivo mobile o un'app web tradizionale. L'app effettua 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 ad 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 delle risorse: considera il server delle risorse come un servizio come Facebook, Google o Twitter; o un servizio HR sulla tua intranet; o un servizio partner sulla tua extranet B2B. Apigee Edge è un server delle risorse ogni volta che è richiesta la convalida del token OAuth per elaborare le richieste API. Il server delle risorse ha bisogno di un'autorizzazione prima di fornire le risorse protette all'app.
• Server di autorizzazione: Il server di autorizzazione viene 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 delle risorse. Puoi configurare "endpoint token" su Apigee Edge, nel qual caso Edge assume il ruolo di server di autorizzazione.
• Concessione di autorizzazione: concede all'app l'autorizzazione a recuperare un token di accesso per conto dell'utente finale. OAuth 2.0 definisce quattro "tipi di concessione" specifici. Vedi "Quali sono i tipi di concessione OAuth 2.0" di seguito.
• Token di accesso:una lunga stringa di caratteri che funge da credenziale utilizzata per accedere alle risorse protette. Vedi anche "Che cos'è un token di accesso?" di seguito.
• Risorsa protetta:dati di proprietà del proprietario della risorsa. Ad esempio, l' elenco dei contatti dell'utente, i dati dell'account o altri dati sensibili.

Qual è il ruolo di Apigee Edge?

Puoi proteggere qualsiasi API con proxy tramite Apigee Edge con OAuth 2.0. Edge 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 Edge. Le app registrate possono richiedere token di accesso tramite una delle quattro concessione tipo interazioni.

Apigee fornisce un criterio OAuthV2 sfaccettato che implementa i dettagli di ogni tipo di concessione, rendendo relativamente semplice la configurazione di OAuth su Apigee Edge. Ad esempio, puoi configurare un criterio 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 delle risorse chiamati dal proxy API sicuro devono trovarsi dietro un firewall (ovvero, le risorse non devono essere accessibili tramite mezzi diversi dal proxy API o da un'altra API ben protetta).

Quali sono i tipi di concessione OAuth 2.0 ?

Considera i tipi di concessione come percorsi o interazioni diversi che un'app può intraprendere per ottenere un token di accesso. Ogni tipo di concessione riguarda uno o più casi d'uso e dovrai selezionare i tipi di concessione da utilizzare in base alle tue esigenze. In generale, ogni tipo di concessione presenta vantaggi e svantaggi e dovrai valutare i compromessi in base ai casi d'uso della tua attività. Una considerazione importante è l'"attendibilità" delle app che accederanno ai tuoi dati. In genere, le app di terze parti sono meno attendibili delle app sviluppate e utilizzate all'interno di un' azienda.

Apigee Edge supporta i quattro tipi di concessione OAuth 2.0 principali:

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

Se accedi correttamente, l'app riceverà un codice di autorizzazione che può utilizzare per negoziare un token di accesso con il server di autorizzazione. In genere, questo tipo di concessione viene utilizzato quando l'app risiede su un server anziché sul client. Questo tipo di concessione è considerato altamente sicuro perché l'app client non gestisce né visualizza il nome utente o la password dell'utente per il server delle risorse (ad esempio, l'app non visualizza né gestisce le tue credenziali di Twitter). Questo flusso di tipo di concessione è chiamato anche OAuth "a tre vie".

• Implicito : considerato una versione semplificata del codice di autorizzazione. In genere, questo tipo di concessione viene utilizzato quando l'app risiede 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 concessione, il server di autorizzazione restituisce un token di accesso direttamente quando l'utente viene autenticato, anziché emettere prima un codice di autorizzazione. Le concessioni implicite possono migliorare la reattività dell'app in alcuni casi, ma questo vantaggio deve essere valutato rispetto alle possibili implicazioni per la sicurezza, come descritto nella specifica IETF.
• Credenziali password del proprietario della risorsa : in questo flusso, al client viene emesso un token di accesso quando il nome utente/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.
• Credenziali client : valuta l'utilizzo per le situazioni in cui l'app client agisce per conto proprio. Ovvero, il client è anche il proprietario della risorsa. Questo tipo di concessione viene in genere utilizzato quando l'app deve accedere a un servizio di archiviazione dei dati di backend, ad esempio. L'app deve utilizzare il servizio per svolgere il proprio lavoro e il servizio è altrimenti opaco per l'utente finale. Con questo tipo di concessione, un'app può ricevere un token di accesso presentando l'ID client e le chiavi client secret al server di autorizzazione. Non sono necessari ulteriori passaggi. Edge fornisce una soluzione di credenziali client predefinita 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 portatore) vengono passati nelle intestazioni di autorizzazione, come segue:

$ 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" le 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 i dati sul server delle risorse. Tieni presente che un token di accesso può essere revocato se, ad esempio, l'app viene compromessa. In questo caso, dovrai ottenere un nuovo token di accesso per continuare a utilizzare l'app; tuttavia, non dovrai modificare il nome utente o la password sul server delle risorse protette (ad esempio, Facebook o Twitter).

I token di accesso in genere hanno una scadenza (per motivi di sicurezza). Alcuni tipi di concessione 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 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 può avere accesso solo a risorse specifiche, essere in grado di aggiornare risorse o avere 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).

Registrare un'app

Tutti i client (app) devono registrarsi con il server di autorizzazione OAuth 2.0 da cui intendono richiedere i token di accesso. Quando registri un'app, ricevi un insieme 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ò emettere richieste di codici di autorizzazione o token di accesso al server di autorizzazione. Tieni presente che, sebbene la specifica IETF OAuth chiami queste chiavi ID client e client secret, l'interfaccia utente di Apigee Edge le chiama ID consumatore e secret consumatore. Sono equivalenti.

Riepilogo dei casi d'uso di OAuth 2.0

Il flusso di tipo di concessione OAuth 2.0 che hai scelto di implementare dipende dal tuo caso d'uso specifico, poiché alcuni tipi di concessione sono più sicuri di altri. La scelta dei tipi di concessione dipende dall' attendibilità dell'app client e richiede una valutazione molto attenta, come descritto nella tabella seguente:

Sicurezza di OAuth 2.0 rispetto alla chiave API

La convalida della chiave API richiede che un'app invii una chiave a Edge. La chiave deve essere una chiave utente valida di un'app per sviluppatori Apigee Edge associata al proxy API. Se per qualche motivo devi revocare l'autorizzazione di un'app client a 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 viene concesso un token, 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, potresti memorizzare l'ID dell'utente che effettua la chiamata API e utilizzarlo per personalizzare le chiamate al servizio di destinazione di backend.

Per informazioni dettagliate sulla convalida della chiave API, vedi Chiavi API. Per informazioni sull'utilizzo degli attributi personalizzati con i token OAuth, vedi Personalizzare i token e i codici di autorizzazione.

Risorse consigliate

Lettura

Consulta Scopri di più su OAuth 2.0.