Questa pagina si applica ad Apigee e Apigee hybrid.
Visualizza la documentazione di
Apigee Edge.
Home page di OAuth: visita la home page di OAuth per una visualizzazione generale 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 tratto dalla specifica IETF OAuth 2.0:
"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 o consentendo all'applicazione di terze parti di ottenere l'accesso per suo conto."
Tieni presente 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.
Flusso OAuth 2.0
Ecco il flusso generale per il framework di sicurezza OAuth 2.0. Parleremo di questo flusso in modo più dettagliato in questo argomento, partendo da 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 in esecuzione su un dispositivo mobile o un'app web tradizionale. L'app invia richieste di risorse protette al server delle risorse 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 persona giuridica) 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, ad esempio Facebook, Google o Twitter, oppure a un servizio per RU sulla tua intranet, oppure a un servizio partner sulla tua extranet B2B. Apigee è un server di risorse ogni volta che è necessaria la convalida di un token OAuth per elaborare le richieste API. Il server delle risorse richiede un qualche tipo di autorizzazione prima di pubblicare risorse protette nell'app.
- Server di autorizzazione: il server di autorizzazione, implementato in conformità alla specifica OAuth 2.0, è responsabile della convalida delle concessioni di autorizzazione e dell'emissione dei token di accesso che concedono all'app l'accesso ai dati dell'utente sul server delle risorse. Puoi configurare endpoint 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. Consulta la pagina 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 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.
Integrazione di 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 token di accesso. Gli sviluppatori iniziano registrando le proprie app con Apigee. Le app registrate possono richiedere token di accesso tramite una qualsiasi delle quattro interazioni di tipo di autorizzazione.
Apigee offre un criterio OAuthV2 sfaccettato che implementa i dettagli di ogni tipo di autorizzazione, semplificando la configurazione di OAuth su Apigee. Ad esempio, puoi configurare un criterio che riceve 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 protette devono essere protette da un firewall (in altre parole, 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ò intraprendere per ottenere un token di accesso. Ogni tipo di autorizzazione riguarda 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 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 di quelle sviluppate e utilizzate all'interno di un'azienda.
Apigee supporta i quattro tipi principali di autorizzazione OAuth 2.0:
- codice di autorizzazione: è 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 autorizzazione viene utilizzato quando l'app si trova su un server anziché sul client. Questo tipo di autorizzazione è considerato altamente sicuro perché l'app client non gestisce o vede mai il nome utente o la password dell'utente per il server delle risorse (ovvero, l'app non vede o gestisce mai le tue credenziali Twitter). Questo flusso di tipo di autorizzazione è anche chiamato OAuth a tre vie.
- implicito: viene considerata una versione semplificata del codice di autorizzazione. In genere questo tipo di autorizzazione 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'app 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 concessioni implicite possono migliorare la reattività delle app in alcuni casi, ma questo vantaggio deve essere valutato rispetto alle possibili implicazioni per la sicurezza, come descritto nella specifica IETF.
- credenziali password 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 affidabili. Un vantaggio di questo flusso rispetto all'autenticazione di base è che l'utente presenta il proprio nome utente e la propria password una sola volta. Da quel momento in poi, viene utilizzato il token di accesso.
- credenziali client: puoi utilizzarla in situazioni in cui l'app client agisce per suo conto. In altre parole, il client è anche il proprietario della risorsa. Questo tipo di autorizzazione viene in genere utilizzato quando l'app deve accedere a un servizio di archiviazione dati di backend, ad esempio. L'app deve utilizzare il servizio per svolgere il proprio lavoro, altrimenti il servizio è opaco per l'utente finale. Con questo tipo di autorizzazione, un'app può ricevere un token di accesso presentando il proprio ID client e le chiavi client secret al server di autorizzazione. Non sono necessari ulteriori passaggi. fornisce una soluzione pronta all'uso per le credenziali client, 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 di 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 restrizioni che consentono, ad esempio, all'app di 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 cambiare 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 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 aggiornamento, consulta la specifica OAuth 2.0 di IETF.
Accesso limitato tramite ambiti
Attraverso 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, potrebbe essere in grado di aggiornare le risorse o potrebbe ricevere l'accesso in sola lettura. Nei cosiddetti flussi OAuth a tre vie, di solito l'utente specifica il livello di accesso tramite una pagina per il 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 al 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 chiamata identificatore client, mentre l'altro è una chiave secret denominata 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 di tipo di autorizzazione OAuth 2.0 che hai scelto di implementare dipende dal caso d'uso specifico, poiché alcuni tipi di autorizzazione sono più sicuri di altri. La scelta dei tipi di concessioni dipende dall'affidabilità dell'app del cliente e richiede un'attenta valutazione, come descritto nella seguente tabella:
| Caso d'uso | Attendibilità | Tipi di concessioni di autorizzazione OAuth 2.0 suggeriti | Descrizione |
|---|---|---|---|
| B2B (extranet), intranet, altro |
App altamente affidabili, scritte da sviluppatori interni o da sviluppatori che hanno un rapporto commerciale affidabile con il fornitore di API. App che devono accedere alle risorse per proprio conto. |
|
|
| Siti e portali Intranet |
App attendibili scritte da sviluppatori interni o di terze parti affidabili. 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, gli sviluppatori che si registrano a programmi API pubblici non dovrebbero essere generalmente considerati attendibili. |
|
|
| B2C | Viene coinvolto un singolo utente finale (utente di dispositivi mobili) e le credenziali utente vengono archiviate sul dispositivo mobile. |
|
|
OAuth 2.0 e sicurezza delle chiavi API a confronto
La convalida delle chiavi API richiede un'app per inviare 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 utente in questione. Inoltre, le app client che utilizzano quella chiave non potranno accedere al proxy API. Il token OAuth può essere invece 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, 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, consulta Personalizzazione di token e codici di autorizzazione.
Risorse consigliate
Lettura
Consulta Informazioni su OAuth 2.0.