Questa pagina si applica ad Apigee e Apigee hybrid.
Visualizza la documentazione di
Apigee Edge.
Home page di OAuth: consulta la home page di OAuth per una visualizzazione generale delle indicazioni relative a OAuth fornite da Google.
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 esaminando la specifica OAuth 2.0 di IETF. Ecco la definizione di OAuth 2.0 dalla specifica OAuth 2.0 IETF stessa:
"Il framework di autorizzazione OAuth 2.0 consente a un'applicazione di terze parti di ottenere l'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 suo conto."
La cosa principale è 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 l'utente potrebbe voler accedere da un'app) senza che l'utente sia tenuto a divulgare le proprie credenziali di accesso all'app.
Flusso OAuth 2.0
Ecco il flusso generale per il framework di sicurezza OAuth 2.0. Approfondiremo questo flusso in questo argomento, iniziando con un diagramma che illustra molto il 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: detta anche app. Può essere un'app eseguita su un dispositivo mobile o un'app web tradizionale. L'app invia richieste di asset protetti al server della risorsa per conto del proprietario della risorsa. Il proprietario della risorsa deve concedere all'app l'autorizzazione per accedere alle risorse protette.
- Proprietario della risorsa:viene chiamato anche utente finale. Si tratta in genere 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, sei il proprietario della risorsa, ovvero l'unica persona che può concedere all'app l'accesso ai tuoi dati.
- Server di risorse: pensa al server delle risorse come a 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 è necessaria la convalida del token OAuth per elaborare le richieste API. Il server delle risorse ha bisogno di un qualche tipo di autorizzazione prima di pubblicare risorse protette per l'app.
- Server di autorizzazione:il server di autorizzazione è implementato in conformità alla 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 endpoint dei token su Apigee, nel qual caso Apigee 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 autorizzazione" specifici. Vedi Quali sono i tipi di autorizzazione OAuth 2.0.
- Token di accesso: una lunga stringa di caratteri che funge da credenziale utilizzata per accedere alle risorse protette. Vedi 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.
Dove si inserisce Apigee
Puoi proteggere qualsiasi API inviata tramite proxy tramite Apigee con OAuth 2.0. Apigee include un'implementazione del server di autorizzazione e, in quanto tale, può generare e convalidare i token di accesso. Per iniziare, gli sviluppatori registrano le proprie app con Apigee. Le app registrate possono richiedere token di accesso tramite una delle quattro interazioni di tipo di autorizzazione.
Apigee offre un criterio OAuthV2 multiforme che implementa i dettagli di ogni tipo di autorizzazione, semplificando così la configurazione di OAuth su Apigee. Ad esempio, puoi configurare un criterio che riceva una richiesta di un token di accesso, valuti tutte le credenziali richieste e restituisca un token di accesso se le credenziali sono valide.
Tieni presente che i server delle risorse che le tue chiamate proxy API sicure devono essere protetti da un firewall (vale a dire, le risorse non devono essere accessibili tramite alcun mezzo diverso dal proxy API o da un'altra API ben protetta).
Che cosa sono i tipi di autorizzazione OAuth 2.0?
Considera i tipi di autorizzazione come diversi percorsi o interazioni che un'app può seguire per ottenere un token di accesso. Ogni tipo di autorizzazione è applicabile a uno o più casi d'uso e dovrai selezionare i tipi di autorizzazione da utilizzare in base alle tue esigenze. In generale, ogni tipo di concessione presenta vantaggi e svantaggi e dovrai valutare i vari compromessi in base ai casi d'uso aziendali. Una considerazione importante è l'affidabilità delle app che accederanno ai tuoi dati. In genere, le app di terze parti sono meno affidabili rispetto a quelle sviluppate e utilizzate all'interno di un'azienda.
Apigee supporta i quattro tipi principali di concessioni OAuth 2.0:
- codice di autorizzazione: viene considerato il tipo di autorizzazione 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 notato questo flusso ogni volta che la tua 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 potrà utilizzare per negoziare un token di accesso con il server di autorizzazione. In genere, questo tipo di concessione viene utilizzato quando l'app si trova su un server anziché sul client. Questo tipo di autorizzazione è considerata altamente sicura perché l'app client non gestisce o vede mai il nome utente o la password dell'utente per il server delle risorse (ossia, ad esempio, l'app non vede o gestisce mai le tue credenziali di Twitter). Questo flusso di tipo di autorizzazione è anche chiamato OAuth a tre vie.
- implicit: considerata una versione semplificata del codice di autorizzazione. In genere questo tipo di concessione 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 eseguire l'esecuzione su un server web separato). In questo flusso del 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 concessioni implicite possono migliorare la reattività delle app in alcuni casi, ma questo vantaggio deve essere valutato in base alle possibili implicazioni per la 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 applicazioni altamente affidabili. Un vantaggio di questo flusso rispetto all'autenticazione di base è che l'utente presenta il nome utente e la password una sola volta. Da quel momento in poi, viene utilizzato il token di accesso.
- credenziali client: prendi in considerazione l'utilizzo in situazioni in cui l'app client agisce per conto proprio. In altre parole, il client è anche il proprietario della risorsa. Questo tipo di concessione viene in genere utilizzato quando l'app deve accedere, ad esempio, a un servizio di archiviazione dati di backend. L'app deve utilizzare il servizio per svolgere il proprio lavoro, altrimenti il servizio risulta opaco per l'utente finale. Con questo tipo di autorizzazione, un'app può ricevere un token di accesso presentando il suo ID client e le chiavi 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 di autorizzazione, in questo modo:
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
Il server delle risorse riconosce che il token di accesso rimane per credenziali come nome utente e password. Inoltre, i token di accesso possono essere emessi con limitazioni 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 viene compromessa. In questo caso, dovrai ottenere un nuovo token di accesso per continuare a utilizzare l'app; tuttavia, non dovrai cambiare 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 tipi di autorizzazione consentono al server di autorizzazione di emettere un token di aggiornamento, che permette all'app di recuperare un nuovo token di accesso alla scadenza di quello precedente. Per ulteriori dettagli sui token di accesso e di aggiornamento, consulta la specifica OAuth 2.0 di IETF.
Accesso limitato tramite gli ambiti
Tramite il meccanismo degli ambiti, OAuth 2.0 può concedere a un'app l'accesso limitato alle risorse protette. Ad esempio, un'app potrebbe avere accesso solo a risorse specifiche, essere in grado di aggiornare le risorse o ricevere l'accesso in sola lettura. Nei cosiddetti flussi OAuth a tre vie, in genere l'utente 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 mazzo di chiavi. Uno è una chiave pubblica denominata identificatore client, mentre l'altro è una chiave secret detta 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 di IETF chiama queste chiavi ID client e client secret, l'interfaccia utente di Apigee le chiama ID consumatore e secret del consumatore. Sono equivalenti.
Riepilogo dei casi d'uso di OAuth 2.0
Il flusso del tipo di autorizzazione OAuth 2.0 che scegli di implementare dipende dal caso d'uso specifico, poiché alcuni tipi di autorizzazione sono più sicuri di altri. La scelta dei tipi di autorizzazione dipende dall'affidabilità dell'app client e richiede un'attenta valutazione, come descritto nella tabella seguente:
| Caso d'uso | Affidabilità | Tipi di concessioni per l'autorizzazione OAuth 2.0 suggeriti | Descrizione |
|---|---|---|---|
| B2B (extranet), intranet, altro |
App altamente affidabili, scritte da sviluppatori interni o da sviluppatori che intrattengono una relazione commerciale di fiducia con il fornitore dell'API. App che devono accedere alle risorse per proprio conto. |
|
|
| 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 selezionare le assicurazioni, inviare recensioni o modificare le informazioni personali. |
|
|
| App disponibili pubblicamente | Le app non attendibili sono scritte da sviluppatori di terze parti che non hanno rapporti commerciali affidabili con il fornitore di API. Ad esempio, generalmente gli sviluppatori che si registrano a programmi API pubblici non dovrebbero essere considerati attendibili. |
|
|
| B2C | Viene coinvolto un singolo utente finale (utente di dispositivi mobili) e le credenziali utente vengono memorizzate sul dispositivo mobile. |
|
|
OAuth 2.0 e sicurezza delle chiavi API a confronto
La convalida delle chiavi API richiede che un'app invii una chiave ad Apigee. La chiave deve essere una chiave utente valida di un'app sviluppatore Apigee associata al proxy API. Se per qualche motivo devi revocare l'autorizzazione concessa a un'app client per effettuare chiamate a un proxy, devi revocare la chiave in questione. Inoltre, le app client che utilizzano la chiave non saranno in grado di accedere al proxy API. Invece, 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 ne viene concesso uno, può continuare a utilizzare il proxy API.
Un'altra differenza tra una chiave API e un token è che un token può includere attributi dei metadati che puoi recuperare e utilizzare in un secondo momento. Ad esempio, puoi archiviare l'ID dell'utente che effettua la chiamata API e utilizzarlo per personalizzare le chiamate al servizio di destinazione del backend.
Per maggiori dettagli sulla convalida delle chiavi API, consulta Chiavi API. Per informazioni sull'utilizzo di attributi personalizzati con i token OAuth, vedi Personalizzazione di token e codici di autorizzazione.
Risorse consigliate
Reading
Vedi Informazioni su OAuth 2.0.