Questa pagina si applica a Apigee e Apigee ibrido.
Visualizza la documentazione di
Apigee Edge.
Home page di OAuth: visita la home page di OAuth per una visualizzazione generale delle indicazioni di 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 a leggere 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 un accesso limitato a un servizio HTTP per conto di un proprietario della risorsa tramite l'orchestrazione di 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 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 (come i conti bancari o altre 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, 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
- Cliente:chiamata anche app. Può essere un'app in esecuzione su un dispositivo mobile o un'app web tradizionale. L'app invia al server di risorse richieste di 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. Di solito 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, sei il proprietario della risorsa, ovvero l'unica persona che può concedere all'app l'accesso ai tuoi dati.
- Server di risorse: il server di risorse può essere paragonato a un servizio come Facebook, Google o Twitter, a un servizio RU sulla tua intranet o a un servizio partner sulla tua extranet B2B. Apigee è un server di risorse ogni volta che è richiesta la convalida dei token OAuth per elaborare le richieste API. Il server di risorse necessita di un qualche tipo di autorizzazione prima di distribuire risorse protette nell'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 concedono all'app l'accesso ai dati dell'utente sul server di risorse. È possibile configurare 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 "tipi di autorizzazione" specifici. Consulta Che cosa sono i tipi di autorizzazione OAuth 2.0.
- Token di accesso:una lunga stringa di caratteri che funge da credenziale per accedere alle risorse protette. Consulta la sezione 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.
Dove si trova Apigee
Puoi proteggere qualsiasi API inviata tramite proxy tramite Apigee con OAuth 2.0. Apigee include un'implementazione del server di autorizzazione e, come tale, può generare e convalidare token di accesso. Gli sviluppatori iniziano registrando le loro app con Apigee. Le app registrate possono richiedere i 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 token di accesso, valuta tutte le credenziali richieste e restituisce un token di accesso se le credenziali sono valide.
Tieni presente che gli eventuali server di risorse chiamati dal proxy API sicuro devono essere protetti da un firewall (in altre parole, le risorse non devono essere accessibili tramite mezzi diversi dal proxy API o da un'altra API ben protetta).
Che cosa sono i tipi di autorizzazione OAuth 2.0?
Pensa ai tipi di concessione come ai diversi percorsi o interazioni che un'app può seguire per ottenere un token di accesso. Ogni tipo di concessione gestisce uno o più casi d'uso e dovrai selezionare i tipi di autorizzazione da utilizzare in base alle tue esigenze. In generale, ciascun 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 generale, le app di terze parti sono meno affidabili rispetto a quelle sviluppate e utilizzate all'interno di un'azienda.
Apigee supporta i quattro principali tipi di autorizzazione OAuth 2.0:
- codice di autorizzazione: considerato il tipo di autorizzazione più sicuro. Prima che il server di autorizzazione invii un token di accesso, l'app deve ricevere un codice di autorizzazione dal server di 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 può 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 di risorse (ovvero, ad esempio, l'app non vede o gestisce mai le tue credenziali Twitter). Questo flusso del tipo di autorizzazione è chiamato anche OAuth a tre vie.
- implicita: 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 è implementato in un browser utilizzando JavaScript o un altro linguaggio di scripting (anziché risiedere ed essere in 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. In alcuni casi, le concessioni implicite possono migliorare la reattività dell'app, ma questo vantaggio deve essere valutato in relazione 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 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, ad esempio, 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: valuta la possibilità di utilizzarle in situazioni in cui l'app client agisce per conto proprio. Ciò significa che 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 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 autorizzazione, un'app può ricevere un token di accesso presentando il proprio ID client e le proprie 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 per accedere alle risorse protette. I token delle risorse (chiamati anche token di connessione) vengono passati nelle intestazioni di autorizzazione, come in questo modo:
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
Il server di risorse riconosce 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 dati sul server di 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).
In genere i token di accesso 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 ulteriori dettagli sui token di accesso e 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 può avere accesso solo a risorse specifiche, essere in grado di aggiornare risorse o potrebbe ottenere l'accesso solo in 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 essere registrati con il server di autorizzazione OAuth 2.0 dal quale intendono richiedere i token di accesso. Quando registri un'app, ricevi un set di token. Una è una chiave pubblica denominata Client Identifier, mentre l'altra è 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 l'ID client e il client secret di queste chiavi, nella UI di Apigee le chiamate sono definite come ID e consumer secret. 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 | Attendibilità | Tipi di concessione dell'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 conto proprio. |
|
|
| Siti e portali intranet |
App attendibili scritte da sviluppatori di terze parti interni o 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 un rapporto commerciale affidabile con il fornitore di API. Ad esempio, in genere non dovrebbero essere considerati attendibili gli sviluppatori che si registrano a programmi API pubblici. |
|
|
| B2C | È coinvolto un singolo utente finale (utente di un dispositivo mobile) e le credenziali utente vengono archiviate sul dispositivo mobile. |
|
|
Sicurezza di OAuth 2.0 e 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 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. Inoltre, nessuna app client che utilizza quella chiave non sarà in grado di 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, 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 archiviare l'ID dell'utente che effettua la chiamata API e utilizzarlo per personalizzare le chiamate al servizio di destinazione di 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
Risorse
Consulta l'articolo Informazioni su OAuth 2.0.