Questa pagina si applica a Apigee e Apigee ibridi.
Visualizza
documentazione di Apigee Edge.
Il codice di autorizzazione è uno dei tipi di autorizzazione OAuth 2.0 più comunemente utilizzati. L'autorizzazione il flusso di codice è una configurazione OAuth a tre vie. In questa configurazione, l'utente autentica con il server delle risorse e concede all'app il consenso per accedere alle risorse protette senza divulgare nome utente e password all'app client.
Informazioni su questo argomento
Questo argomento offre una descrizione generale e una panoramica del tipo di concessione dell'autorizzazione OAuth 2.0 e spiega come implementarlo su Apigee.
Video
Guarda un breve video per scoprire come utilizzare il tipo di concessione dell'autorizzazione OAuth 2.0 per proteggere le tue API.
Casi d'uso
Questo tipo di autorizzazione è destinato alle app scritte da sviluppatori di terze parti che non Avere un rapporto commerciale affidabile con il fornitore dell'API. Ad esempio, gli sviluppatori che si registrano per i programmi API pubblici in genere non dovrebbero essere considerati attendibili. Con questo tipo di autorizzazione, le credenziali sul server di risorse non vengono mai condivise con l'app.
Esempio di codice
Puoi trovare un esempio completo e funzionante del tipo di concessione del codice di autorizzazione su
Apigee nel repository api-platform-samples
su GitHub. Consulta la guida oauth-advanced
esempio nella directory api-platform-samples/sample-proxies. Consulta
README per maggiori dettagli sul campione.
Diagramma di flusso
Il seguente diagramma di flusso illustra il flusso OAuth del codice di autorizzazione con Apigee fungendo da server di autorizzazione.
Passaggi nel flusso del codice di autorizzazione
Ecco un riepilogo dei passaggi necessari per implementare il tipo di concessione del codice di autorizzazione in cui Apigee funge da server di autorizzazione. Ricorda che la chiave di questo flusso è che il client non vede mai le credenziali dell'utente sul server delle risorse.
Prerequisito: l'app client deve essere registrata con Apigee per recuperare l'ID e le chiavi del client secret. Consulta Registrazione di app client per i dettagli.
1. L'utente avvia il flusso
Quando l'app deve accedere alle risorse protette dell'utente da un server di risorse (ad contatti su un sito di social media), invia una chiamata API ad Apigee, che convalida l'ID client e, se è valido, reindirizza il browser dell'utente a una pagina di accesso in cui l'utente inserirà le proprie credenziali. La chiamata API include informazioni che l'app client ottenuti al momento della registrazione: ID client e URI di reindirizzamento.
2. L'utente inserisce le credenziali
A questo punto, l'utente vede una pagina di accesso in cui gli viene chiesto di inserire le credenziali di accesso. Se Se l'accesso è riuscito, andiamo al passaggio successivo.
3. L'utente dà il consenso
In questo passaggio, l'utente concede all'app il consenso per accedere alle proprie risorse. Il modulo di consenso in genere include selezioni degli ambiti in cui l'utente può scegliere quali operazioni può eseguire l'app il server di risorse. Ad esempio, l'utente potrebbe concedere l'autorizzazione di sola lettura o l'autorizzazione per l'app per aggiornare le risorse.
4. App di accesso invia una richiesta ad Apigee
Se l'accesso e il consenso hanno esito positivo, l'app di accesso PUBBLICA i dati in /Authorizationcode endpoint di Apigee. I dati includono l'URI di reindirizzamento, l'ID client, l'ambito, eventuali informazioni che desidera includere e un'indicazione che l'accesso è riuscito.
5. Apigee genera un codice di autorizzazione
Quando Apigee riceve una richiesta GET dall'app di accesso sul suo endpoint /Authorizationcode, succedono cose. Innanzitutto, Apigee determina che l'accesso è riuscito (controllando lo stato HTTP o in altri modi). Successivamente, Apigee controlla che l'URI di reindirizzamento inviato dall'app di accesso corrisponde all'URI di reindirizzamento specificato al momento della registrazione dell'app con Apigee. Se va tutto bene, Apigee genera un codice di autorizzazione. Ad esempio:
http://myorg-test.apigee.net/oauth/authorizationcode?client_id={consumer_key}&response_type=code&redirect_uri={redirect_uri}&scope=scope1%20scope2&state={some_string}
6. Apigee restituisce il codice di autorizzazione al client
Apigee invia un reindirizzamento 302 con il codice di autorizzazione allegato come parametro di query alla di alto profilo.
7. Il client recupera il codice di autorizzazione e richiede un codice di accesso ad Apigee
Ora, con un codice di autorizzazione valido, il client può richiedere un token di accesso ad Apigee. Per farlo, POSTando l'ID client e le chiavi client secret (ottenute al momento della registrazione dell'app su Apigee), tipo di autorizzazione e ambito. Includendo l'ID client e le chiavi private che Apigee può verificare che l'app client sia quella registrata. Ad esempio:
$ curl https://{org_name}-test.apigee.net/my_oauth_proxy/accesstoken?code=Xyz123&grant_type=authorization_code -X POST -d 'client_id=bBGAQrXgivA9lKu7NMPyoYpKNhGar6K&client_secret=hAr4GngA9vAyvI4'
8. Il cliente riceve un token di accesso
Se tutto va a buon fine, Apigee restituisce un token di accesso al client. Il token di accesso hanno una scadenza, che sarà valida solo per l'ambito specificato dall'utente quando ha fornito il consenso dell'app ad accedere alle sue risorse.
9. Il cliente chiama API Protected
Ora, con un codice di accesso valido, il client può effettuare chiamate all'API protetta. In questo le richieste vengono inviate ad Apigee (il proxy), che è responsabile della convalida il token di accesso prima di passare la chiamata API al server di risorse di destinazione. Token di accesso vengono passate in un'intestazione Autorizzazione. Ad esempio:
$ curl -H "Authorization: Bearer ylSkZIjbdWybfs4fUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282
Configurazione di flussi e criteri
In qualità di server di autorizzazione, Apigee deve elaborare una serie di richieste OAuth: per l'accesso token, codici di autorizzazione, token di aggiornamento, reindirizzamenti alla pagina di accesso e così via. Esistono due passaggi fondamentali per configurare questi endpoint:
- Creazione di flussi personalizzati
- Aggiunta e configurazione dei criteri OAuthV2
Configurazione del flusso personalizzato
In genere configuri questo flusso del tipo di autorizzazione in modo che sia definito ogni passaggio o gamba del flusso.
da un flusso nel proxy Apigee. Ogni flusso ha un endpoint e un criterio che esegue
È richiesta un'attività specifica per OAuth, ad esempio la generazione di un codice di autorizzazione o di un token di accesso. Per
Ad esempio, come mostrato nel codice XML di seguito, l'endpoint /oauth/authorizationcode
ha un
associato chiamato GeneraAuthCode (che è un criterio OAuthV2 con
dell'operazione generateAuthorizationCode specificata).
Il modo più semplice per mostrare la configurazione del flusso è con un esempio XML. Guarda in linea commenti per informazioni su ogni flusso. Questo è un esempio: i nomi di flussi e percorsi possono configurarla come desideri. Vedi anche Configurazione di OAuth endpoint e criteri per una rapida panoramica dei passaggi necessari per creare un flusso personalizzato in questo modo.
Vedi anche l'esempio implementazione su GitHub.
<Flows>
<Flow name="RedirectToLoginApp">
<!--
Publish this URI to developers to use for their 'login' link
-->
<Condition>proxy.pathsuffix == "/oauth/authorize"</Condition>
<Request>
<Step><Name>RedirectToLoginPage</Name></Step>
</Request>
</Flow>
<Flow name="GetAuthCode">
<!--
Call this URL from your Login app after you authenticate the user.
The policy will automatically return the auth code in the response to the
redirect_uri registered by the calling app
-->
<Condition>proxy.pathsuffix == "/oauth/authorizationcode"</Condition>
<Request>
<Step><Name>GenerateAuthCode</Name></Step>
</Request>
</Flow>
<Flow name="GetAccessToken">
<!-- This policy flow is triggered when the URI path suffix
matches /oauth/accesstoken. Publish this URL to app developers
to use when obtaining an access token using an auth code
-->
<Condition>proxy.pathsuffix == "/oauth/accesstoken"</Condition>
<Request>
<Step><Name>GenerateAccessToken</Name></Step>
</Request>
</Flow>
</Flows>
Configurare i flussi con i criteri
A ogni endpoint è associato un criterio. Vediamo alcuni esempi di norme. Consulta anche Configurare OAuth endpoint e criteri per una rapida panoramica dei passaggi necessari per aggiungere i criteri OAuthV2. agli endpoint proxy.
Reindirizzamento accesso
Questo è il percorso /oauth/authorize
. Il criterio allegato è responsabile
Reindirizzando l'utente a un'app di accesso, dove l'utente finale può autenticare e autorizzare in modo sicuro
di accedere alle risorse protette senza divulgare nome utente e password a un'app client
l'app client. Puoi farlo con un criterio per i callout dei servizi, JavaScript o
in altri modi.
La chiamata API per eseguire la richiesta è GET e richiede i parametri di ricerca client_id, response_type, Redirect_uri, scope e state.
$ curl http://myorg-test.apigee.net/oauth/authorize?client_id={consumer_key}&response_type=code&redirect_uri={redirect_uri}&scope=scope1%20scope2&state={some_string}
Richiedi codice di autorizzazione
Questo è il percorso /oauth/authorizationcode
. Utilizza il criterio OAuthV2 con il parametro
Operazione generaAuthorizationCode specificata.
<OAuthV2 async="false" continueOnError="false" enabled="true" name="GetAuthCode"> <DisplayName>GetAuthCode</DisplayName> <Operation>GenerateAuthorizationCode</Operation> <ExpiresIn>600000</ExpiresIn> <GenerateResponse/> </OAuthV2>
La chiamata API per ottenere il codice di autorizzazione è di tipo GET e richiede i parametri di ricerca client_id, response_type e, facoltativamente, ambito e stato, come mostrato in questo esempio:
$curl http://myorg-test.apigee.net/oauth/authorizationcode?client_id={consumer_key}&response_type=code&scope=scope1%20scope2&state={some_string}
Richiedi token di accesso
Questo criterio è collegato al percorso /oauth/accesstoken
. Utilizza il protocollo OAuthV2
con l'operazione generateAccessCode specificata. In questo caso, il parametro allow_type è
previsto come parametro di query:
<OAuthV2 name="GetAccessToken"> <Operation>GenerateAccessToken</Operation> <ExpiresIn>360000000</ExpiresIn> <SupportedGrantTypes> <GrantType>authorization_code</GrantType> </SupportedGrantTypes> <GrantType>request.queryparam.grant_type</GrantType> <GenerateResponse/> </OAuthV2>
La chiamata API per ottenere il codice di accesso è un POST e deve includere client_id, client_secret,grant_type=authorization_code e, facoltativamente, all'ambito. Ad esempio:
$ curl https://{org_name}-test.apigee.net/oauth/accesstoken?grant_type=authorization_code -X POST -d 'client_id=bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K&client_secret=hAr4Gn0gA9vAyvI4'
Questo è solo un riepilogo di base. Un esempio di produzione include molti altri criteri per lo sviluppo l'esecuzione di URL, trasformazioni e altre attività. Fai riferimento all'esempio su GitHub per una progetto completo e funzionante.
Collegamento del criterio di verifica del token di accesso in corso...
Collega un criterio VerifyAccessToken (criterio OAuthV2 con l'operazione VerifyAccessToken specificato) all'inizio di qualsiasi flusso che accede a un'API protetta, in modo che venga eseguito ogni volta che arriva una richiesta di risorse protette. Apigee controlla che ogni richiesta abbia token di accesso valido. In caso contrario, viene restituito un errore. Per i passaggi di base, vedi Verificare i token di accesso.
<OAuthV2 async="false" continueOnError="false" enabled="true" name="VerifyAccessToken"> <DisplayName>VerifyAccessToken</DisplayName> <ExternalAuthorization>false</ExternalAuthorization> <Operation>VerifyAccessToken</Operation> <SupportedGrantTypes/> <GenerateResponse enabled="true"/> <Tokens/> </OAuthV2>
Chiamata all'API protetta
Per chiamare un'API protetta con la sicurezza OAuth 2.0, devi presentare un accesso valido di accesso. Il pattern corretto consiste nell'includere il token in un'intestazione Autorizzazione, come segue: Nota che il token di accesso è indicato anche come token di connessione.
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
Vedi anche Invio di un di accesso al token.