Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione
Documentazione di Apigee X. Informazioni
OAuth è emerso come il protocollo di autorizzazione principale per le API. Versione di OAuth trattato in dettaglio in questo argomento è definito nel documento OAuth: 2.0 Specifiche.
OAuth è un protocollo che consente agli utenti finali di app di autorizzare app di agire per loro conto. Le app lo fanno ottenendo l'accesso di token dei fornitori di API. Il provider API autentica l'estremità dell'app le credenziali dell'utente, garantisce che l'utente abbia autorizzato l'app e quindi emette un token di accesso all'app. Quando l'app utilizza un'API protetta, Apigee Edge controlla il token di accesso per garantire che sia valido e che non sia scaduto. In qualità di provider API, devi esporre gli endpoint che consentono alle app di ottenere token di accesso.
Per semplificare l'utilizzo di OAuth, Apigee Edge consente di configurare e applicare in modo forzato OAuth utilizzando i criteri, senza richiedere scrivere alcun codice. In questo argomento scoprirai come proteggere le API, come ottenere l'accesso e come utilizzarli per accedere alle API protette.
La configurazione OAuth predefinita per organizzazione
Per praticità, tutte le organizzazioni su Apigee Edge sono preconfigurate con un set di OAuth 2.0 endpoint che implementano il tipo di concessione delle credenziali client. Il cliente Il tipo di concessione delle credenziali definisce una procedura per l'emissione di token di accesso in cambio di app credenziali. Queste credenziali dell'app sono semplicemente la coppia chiave utente e segreto che Problemi di Apigee Edge per ogni app registrata in un'organizzazione. Credenziali client si riferisce alla coppia chiave-segreta e chiave utente stessa.
Per ulteriori informazioni sull'emissione di credenziali alle app utilizzando Edge Developer Services, vedi Registrare app e gestire le chiavi.
Per questo motivo, è relativamente semplice "intensificare" lo schema di sicurezza dell'API dalla chiave API la convalida delle credenziali per il client OAuth. Entrambi gli schemi utilizzano la stessa chiave utente e lo stesso segreto convalidare l'app client. La differenza è che le credenziali client forniscono un ulteriore livello controllo, poiché puoi revocare facilmente un token di accesso quando necessario, senza dover revocare chiave utente dell'app. Per utilizzare gli endpoint OAuth predefiniti, puoi utilizzare qualsiasi chiave utente e il secret generati per l'app nella tua organizzazione per recuperare i token di accesso dal token endpoint. Puoi anche abilitare le credenziali client per le app che dispongono già di chiavi consumer e secrets.)
La specifica completa per la concessione delle credenziali client è disponibile nel sito web OAuth 2.0 Specifiche.
Proteggi l'API con un criterio
Prima di poter utilizzare i token di accesso, devi configurare le API per convalidare l'accesso OAuth in fase di runtime. Per farlo, devi configurare un proxy API convalidare i token di accesso. Ciò significa che, ogni volta che un'app invia una richiesta utilizzi una delle tue API, l'app deve presentare un token di accesso valido insieme alla richiesta API. Apigee Edge gestisce la complessità dietro la generazione, l'archiviazione e la convalida dei token di accesso presentati.
Puoi aggiungere facilmente la verifica OAuth a un'API quando crei un nuovo proxy API. Quando crei un nuovo proxy API, puoi aggiungere caratteristiche. Come mostrato di seguito, puoi aggiungere la verifica dei token di accesso OAuth 2.0 selezionando il pulsante di opzione accanto a Proteggi con i token di accesso OAuth v2.0. Quando selezioni questa opzione, verranno collegati al proxy API appena creato, uno per verificare i token di accesso e l'altro per rimuovere il token di accesso dopo la verifica.
Inoltre, quando selezioni l'opzione Secure with OAuth v2.0 Access Tokens (Proteggi con i token di accesso OAuth v2.0), la casella di controllo Pubblica prodotto API diventa selezionabile e viene automaticamente selezionato. Seleziona questa opzione se vuoi generare automaticamente un prodotto quando crei la nuova API proxy. Il prodotto generato automaticamente verrà creato con un'associazione al nuovo proxy API. Se un prodotto esistente a cui desideri associare la nuova API, assicurati di cancellare per evitare di creare un prodotto non necessario. Per informazioni sui prodotti, vedi Che cos'è un prodotto API?
Se devi abilitare la verifica del token di accesso per il proxy API già esistente, è sufficiente collegare un criterio di tipo OAuthV2 all'API che che vuoi proteggere. I criteri OAuthV2 funzionano specificando un'operazione. Se vuoi per convalidare i token di accesso, devi specificare l'operazione denominata VerifyAccessToken. (Altri tipi di operazioni che sono supportati dal tipo di criterio OAuthV2 sonoGenerateAccessToken e GenerateRefreshToken. Imparerai queste operazioni quando configuri endpoint OAuth.)
Criterio VerifyOAuthTokens di tipo OAuthV2
Un criterio di esempio per la convalida dei token di accesso è simile al seguente. (le impostazioni sono spiegata nella tabella riportata di seguito).
<OAuthV2 name="VerifyOAuthTokens"> <Operation>VerifyAccessToken</Operation> </OAuthV2>
Impostazioni criteri
| Nome | Descrizione | Predefinito | Obbligatorio? |
|---|---|---|---|
OAuthV2 |
Il tipo di criterio | ||
name |
Il nome del criterio, a cui viene fatto riferimento nell'endpoint del proxy API configurazione. | N/D | Sì |
Operation |
L'operazione che deve essere eseguita dal criterio OAuthV2. Se specifichi VerifyAccessToken, il criterio viene configurato per controllare le richieste dei token di accesso e per verificare che l'accesso token è valido, non è scaduto ed è approvato per utilizzare la risorsa API richiesta (URI). Per effettuare questo controllo, le norme leggono il prodotto API per cui l'app è approvata consume.) | N/D | Sì |
Per creare questo criterio nell'interfaccia utente di gestione, vai ad API > API Proxy.
Dall'elenco dei proxy API, seleziona weatherapi.
Dalla Panoramica di weatherapi, seleziona lo strumento Develop vista.
Dal menu a discesa, seleziona Nuova norma > OAuth versione 2.0
Dopo aver selezionato il criterio OAuth 2.0, viene visualizzato il menu di configurazione Nuovo criterio. .
Assegna al criterio un nome descrittivo e assicurati di selezionare Allega norma. Flow PreFlow e Request come impostazioni di collegamento dei criteri.
Seleziona Aggiungi e il criterio viene creato e associato alla richiesta del meteo. PreFlow.
Una volta aggiunto il criterio, la configurazione PreFlow della richiesta riportata di seguito verrà visualizzata nel Riquadro Designer.
Se lavori localmente in un editor di testo o in un IDE, allega il criterio alla richiesta PreFlow del proxy API che vuoi proteggere:
<PreFlow>
<Request>
<Step><Name>VerifyOAuthTokens</Name></Step>
</Request>
</PreFlow>
Se colleghi il criterio alla richiesta PreFlow, ti assicuri che venga applicato sempre a tutti i messaggi di richiesta.
Hai protetto un'API con credenziali client OAuth 2.0. Il prossimo passaggio è scoprire per ottenere un token di accesso e utilizzarlo per accedere all'API sicura.
L'utilizzo di un token di accesso per accedere a un risorsa
Ora che la Weatherapi è protetta con OAuth 2.0, le app devono presentare token di accesso per l'utilizzo l'API. Per accedere a una risorsa protetta, l'app presenta un token di accesso nella richiesta come "Autorizzazione" Intestazione HTTP come segue:
$ curl -H "Authorization: Bearer ylSkZIjbdWybfs4fUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282
Poiché all'API è collegato un criterio OAuthV2, Apigee Edge verificherà che il token di accesso presentato sia valido, poi concede l'accesso all'API restituendo il bollettino meteo all'app che ha effettuato la richiesta.
In che modo le app ricevono i token di accesso? Ne parleremo nella prossima sezione.
Come scambiare le credenziali client per un token di accesso
Le app ottengono i token di accesso presentando le loro coppie chiave/segreto utente al token. endpoint. L'endpoint del token è configurato nel proxy API chiamato oauth. Quindi le app devono chiamare l'API esposta dall'API oauth per ottenere un token di accesso. Dopo aver ricevuto un token di accesso, l'app può chiamare la funzione più volte, fino alla scadenza del token di accesso o alla revoca del token di accesso.
Ora devi cambiare marcia per pensare a te stesso come sviluppatore di app. Vuoi chiamare il meteoapi, devi quindi ottenere un token di accesso per la tua app. La prima cosa da fare è Ottenere una coppia chiave utente e token segreto (nota anche come API o una chiave dell'app).
Puoi ottenere una chiave utente e un segreto registrando un'app nella tua organizzazione su Apigee perimetrali.
Puoi visualizzare tutte le app nella tua organizzazione nell'interfaccia utente di gestione di Apigee Edge.
Verrà visualizzato l'elenco di app registrate nella tua organizzazione.
Se non viene visualizzata alcuna app, puoi scoprire come registrare un'app nell'argomento Registrare app e gestire l'API chiavi.
Seleziona un'app dall'elenco per visualizzarne il profilo dettagliato.
Nella visualizzazione dei dettagli dell'app selezionata, controlla i campi di Consumer Key. e Segreto utente. Questi due valori sono il client credenziali che utilizzerai per ottenere un token di accesso OAuth.
$ curl https://api.enterprise.apigee.com/v1/o/{org_name}/apps \
-u myname:mypass
Questa chiamata restituisce un elenco di app per ID app.
[ "da496fae-2a04-4a5c-b2d0-709278a6f9db", "50e3e831-175b-4a05-8fb6-05a54701af6e" ]
Puoi recuperare il profilo di un'app effettuando una semplice chiamata GET sull'ID app:
$ curl https://api.enterprise.apigee.com/v1/o/{org_name}/apps/{app_id} \
-u myname:mypass
Ad esempio:
$ curl https://api.enterprise.apigee.com/v1/o/{org_name}/apps/da496fae-2a04-4a5c-b2d0-709278a6f9db \
-u myname:mypass
La chiamata API restituisce il profilo dell'app che hai specificato. Ad esempio, un profilo dell'app per weatherapp ha la seguente rappresentazione JSON:
{
"accessType" : "read",
"apiProducts" : [ ],
"appFamily" : "default",
"appId" : "da496fae-2a04-4a5c-b2d0-709278a6f9db",
"attributes" : [ ],
"callbackUrl" : "http://weatherapp.com",
"createdAt" : 1380290158713,
"createdBy" : "noreply_admin@apigee.com",
"credentials" : [ {
"apiProducts" : [ {
"apiproduct" : "PremiumWeatherAPI",
"status" : "approved"
} ],
"attributes" : [ ],
"consumerKey" : "bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K",
"consumerSecret" : "hAr4Gn0gA9vAyvI4",
"expiresAt" : -1,
"issuedAt" : 1380290161417,
"scopes" : [ ],
"status" : "approved"
} ],
"developerId" : "5w95xGkpnjzJDBT4",
"lastModifiedAt" : 1380290158713,
"lastModifiedBy" : "noreply_admin@apigee.com",
"name" : "weatherapp",
"scopes" : [ ],
"status" : "approved"
}
Prendi nota dei valori di consumerKey e consumerSecret. Utilizzi questi
per ottenere un token di accesso presentandole come credenziali di autenticazione di base
una richiesta HTTP, come mostrato di seguito. Il tipo di concessione viene presentato come parametro di ricerca alla richiesta.
Assicurati di modificare il valore della variabile {org_name} in modo che rifletta il nome della tua organizzazione.
su Apigee Edge).
Crea una richiesta per ottenere un token di accesso
Nella richiesta seguente, sostituisci il valore di consumerKey con
client_id. Sostituisci il valore dell'elemento consumerSecret associato con
client_secret.
$ curl https://{org_name}-test.apigee.net/oauth/client_credential/accesstoken?grant_type=client_credentials -X POST -d 'client_id=bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K&client_secret=hAr4Gn0gA9vAyvI4'
I servizi API verificano la chiave e il segreto utente e quindi generano una risposta contenente token di accesso per questa app:
{
"issued_at" : "1380892555397",
"application_name" : "957aa73f-25c2-4ead-8021-adc01f0d2c6b",
"scope" : "",
"status" : "approved",
"api_product_list" : "[oauth-test]",
"expires_in" : "3599",
"developer.email" : "tesla@weathersample.com",
"organization_id" : "0",
"client_id" : "bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K",
"access_token" : "ylSkZIjbdWybfs4fUQe9BqP0LH5Z",
"organization_name" : "rqa",
"refresh_token_expires_in" : "0",
"refresh_count" : "0"
}
Prendi nota del valore access_token nella risposta riportata sopra. Si tratta del token di accesso
che l'app utilizzerà per ottenere l'accesso in fase di runtime alle risorse protette. Il token di accesso per questa app è
ylSkZIjbdWybfs4fUQe9BqP0LH5Z.
Ora disponi di un token di accesso valido, ylSkZIjbdWybfs4fUQe9BqP0LH5Z, che può essere utilizzato
per accedere alle API protette.
Utilizzo della configurazione OAuth predefinita
A ogni organizzazione (anche in prova senza costi) su Apigee Edge viene eseguito il provisioning di un token OAuth endpoint. L'endpoint è preconfigurato con criteri nel proxy API chiamato oauth. Puoi iniziare a utilizzare l'endpoint del token non appena crei un account su Apigee Edge.
L'endpoint OAuth predefinito espone il seguente URI dell'endpoint:
/oauth/client_credential/accesstoken
Pubblica questo URI per gli sviluppatori che devono ottenere i token di accesso. Gli sviluppatori di app configurano le loro app per chiamare questo endpoint, presentando le loro coppie chiave utente e segreto per ottenere l'accesso di token.
L'endpoint del token delle credenziali client predefinito è esposto sulla rete al seguente indirizzo: URL:
https://{org_name}-{env_name}.apigee.net/oauth/client_credential/accesstoken
Ad esempio, se il nome della tua organizzazione è "apimaker", l'URL sarà:
https://apimakers-test.apigee.net/oauth/client_credential/accesstoken
Si tratta dell'URL chiamato dagli sviluppatori per ottenere i token di accesso.
Configurazioni OAuth a tre vie
Configurazioni OAuth a tre vie (codice di autorizzazione, autorizzazione implicita e password tipi) richiedono al provider API di autenticare gli utenti finali dell'app. Poiché ogni l'organizzazione autentica gli utenti in diversi modi; è richiesta una certa personalizzazione dei criteri o del codice per integrare OAuth con il tuo archivio utenti. Ad esempio, tutti gli utenti potrebbero essere archiviati in Directory, in un LDAP o in un altro archivio utenti. Per attivare OAuth a tre vie, devi integrare un controllo relativo a questo archivio utente nel flusso OAuth complessivo.
OAuth 1.0a
Per maggiori dettagli sul criterio OAuth 1.0a, vedi Criterio OAuth v1.0a.
Ricevi assistenza
Per assistenza, visita il sito Apigee Assistenza clienti.