Questa pagina si applica ad Apigee e Apigee hybrid.
Visualizza
documentazione di Apigee Edge.
Home page di OAuth: visita la home page di OAuth per una visualizzazione di primo 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 inizia leggendo le informazioni sul codice OAuth 2.0 di IETF la specifica del prodotto. Ecco la definizione di OAuth 2.0 dalla specifica OAuth 2.0 per IETF stesso:
"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 del proprietario di una 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."
L'aspetto principale da sapere è che OAuth 2.0 consente alle app di ottenere accesso limitato alle risorse protette di un utente (ad esempio il conto bancario 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.
Il flusso OAuth 2.0
Ecco il flusso generale per il framework di sicurezza OAuth 2.0. Discuteremo questo flusso in modo più dettagliato in questo argomento, iniziando con un diagramma che illustra molto bene il funzionamento di OAuth 2.0. Se non hai dimestichezza con i termini usati in questo diagramma, leggi questa sezione per una rapida l'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 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. Di solito si tratta persona (o 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 di risorse come a un servizio come Facebook, Google o Twitter; un servizio HR sulla tua intranet; o un servizio di 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 di risorse necessita di un qualche tipo di autorizzazione prima di essere pubblicato le 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 consentono all'app di accedere ai dati dell'utente sul server di risorse. Puoi configurare gli endpoint dei token su Apigee, in questo caso Apigee assume il ruolo di server di autorizzazione.
- Concessione dell'autorizzazione:concede all'app l'autorizzazione a recuperare un accesso. per conto dell'utente finale. OAuth 2.0 definisce quattro "tipi di autorizzazione" specifici. Consulta: Quali sono i tipi di autorizzazione OAuth 2.0?
- Token di accesso:una lunga stringa di caratteri che funge da credenziale utilizzate per accedere alle risorse protette. Consulta Che cos'è un token di accesso?.
- Risorsa protetta:dati di proprietà del proprietario della risorsa. Ad esempio, elenco contatti, i dati dell'account o altri dati sensibili dell'utente.
Il ruolo di Apigee
Puoi proteggere qualsiasi API sottoposta a proxy tramite Apigee con OAuth 2.0. Apigee include dell'implementazione del server di autorizzazione e, come tale, può generare e convalidare i token di accesso. Gli sviluppatori iniziano registrando le loro app con Apigee. Le app registrate possono richiedere i token di accesso tramite una delle quattro concessioni tipo di interazione.
Apigee offre un criterio OAuthV2 sfaccettato che implementa dettagli di ogni tipo di autorizzazione, semplificando la configurazione di OAuth su Apigee. Per Ad esempio, puoi configurare un criterio che riceve una richiesta di token di accesso, che valuta tutti credenziali obbligatorie 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 tramite nessun altro mezzo oltre al proxy API o a un'altra API ben protetta).
Quali sono i tipi di autorizzazioni OAuth 2.0?
Pensa ai tipi di concessione come ai diversi percorsi o interazioni che un'app può intraprendere per ottenere l'accesso di accesso. Ogni tipo di autorizzazione riguarda uno o più casi d'uso e dovrai selezionare quale concessione tipi da utilizzare in base alle proprie esigenze. In generale, ciascun tipo di concessione offre vantaggi e dovrai valutare i compromessi in base ai casi d'uso aziendali. Uno. 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 per l'azienda.
Apigee supporta i quattro tipi principali di concessioni 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 prima ricevere un codice di autorizzazione dal server di risorse. Hai notato questo flusso ogni volta che la tua app apre un browser sul pagina di accesso del server di risorse e ti invita ad accedere al tuo account effettivo (ad esempio Facebook o Twitter).
Se accedi correttamente, l'app riceverà un'autorizzazione codice 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 risiede su un server anziché sul client. Questo tipo di concessione è considerato molto 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 di Twitter). Questo flusso del tipo di autorizzazione è chiamato anche OAuth a tre vie.
- implicito: considerato 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 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. In alcuni casi, le concessioni implicite possono migliorare la reattività dell'app, ma è necessario valutare questo vantaggio rispetto alle possibili implicazioni per la sicurezza, come descritto specifica IETF.
- credenziali per la password del proprietario della risorsa: in questo flusso, il 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 deve inserire il nome utente/la password una sola volta. Da quel momento, viene utilizzato il token di accesso.
- credenziali client. Prendi in considerazione l'utilizzo in situazioni in cui il client che l'app agisce per conto proprio. Ciò significa che il client è anche il proprietario della risorsa. Questa concessione di solito viene usato quando l'app deve accedere a un servizio di archiviazione dati di backend, esempio. L'app deve utilizzare il servizio per svolgere il proprio lavoro e il servizio è altrimenti oscurato per l'utente finale. Con questo tipo di autorizzazione, un'app può ricevere un token di accesso presentando il suo l'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.
Cos'è un accesso di accesso al token?
Un token di accesso è una lunga stringa di caratteri che funge da credenziale per accedere e risorse protette. I token delle risorse (chiamati anche token bearer) vengono passati nelle intestazioni Authorization, come segue:
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
Il server di risorse comprende che il token di accesso sostituisce le 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 di risorse. Tieni presente che un token di accesso può essere revocato se, ad esempio, l'app è compromessa. In questo caso, avrai bisogno richiedere un nuovo token di accesso per continuare a utilizzare l'app; tuttavia non dovrai modificare nome utente o 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 server di autorizzazione per emettere un token di aggiornamento, che consente all'app di recuperare un nuovo token di accesso alla scadenza di quella precedente. Per ulteriori dettagli sui token di accesso e aggiornamento, consulta la specifica OAuth 2.0 di IETF.
Accesso limitato tramite ambiti
Tramite il meccanismo degli ambiti, OAuth 2.0 può concedere a un'app l'accesso limitato Google Cloud. Ad esempio, un'app potrebbe avere accesso solo a risorse specifiche, potrebbe essere in grado di aggiornare le risorse o potrebbe essere concesso solo l'accesso in sola lettura. Nei cosiddetti flussi OAuth a tre vie, l'utente specifica in genere 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 (le app) devono registrarsi al server di autorizzazione OAuth 2.0 da cui vogliono richiedere i token di accesso. Quando registri un'app, ricevi un set di token. Il primo è una chiave pubblica denominata identificatore client, mentre l'altra è una chiave segreta denominata client il 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, anche se la specifica OAuth di IETF chiama questo client di chiavi e client secret, la UI di Apigee li chiama ID consumatore e segreto utente. 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, ad esempio: alcuni tipi di autorizzazione sono più sicuri di altri. La scelta dei tipi di concessione dipende dall'affidabilità dell'app client e richiede un'attenta considerazione, 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 attendibili, scritte da uno sviluppatore interno o da sviluppatori con un rapporto commerciale attendibile con il fornitore dell'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 è accedere 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'attività affidabile e la relazione con il provider API. Ad esempio, gli sviluppatori che si registrano all'API pubblica generalmente non dovrebbero essere affidabili. |
|
|
| 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
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 per consentire a un'app client di effettuare chiamate a un proxy, devi revocare la chiave consumer. Inoltre, nessuna app client che utilizza quella chiave non sarà in grado di accedere al proxy API. Il giorno invece, un token OAuth può essere revocato in qualsiasi momento senza revocare le chiavi dell'app. L'app può richiedere un nuovo token per conto dell'utente e, se viene concesso il token, l'app può per continuare a utilizzare il proxy API.
Un'altra differenza tra una chiave API e un token è che un token può includere metadati che puoi recuperare e utilizzare in un secondo momento. Ad esempio, puoi archiviare l'ID dell'utente effettuando la chiamata API e la useremo per personalizzare le chiamate al servizio di destinazione backend.
Per informazioni dettagliate sulla convalida delle chiavi API, consulta Chiavi API. Per informazioni sull'utilizzo degli attributi personalizzati con i token OAuth, consulta Personalizzare token e codici di autorizzazione.
Consigliati risorse
Lettura
Consulta la sezione Informazioni su OAuth 2.0.