Questa pagina è stata tradotta dall'API Cloud Translation.

Implementazione del tipo di concessione del codice di autorizzazione

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Il codice di autorizzazione è uno dei tipi di autorizzazione OAuth 2.0 più comunemente utilizzati. L'autorizzazione un flusso di codice "OAuth a tre vie" configurazione. 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 parleremo di come implementarlo su Apigee Edge.

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 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 Edge 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 Edge fungendo da server di autorizzazione.

Suggerimento: per vedere una versione più grande di questo diagramma, fai clic con il tasto destro del mouse sul diagramma e aprilo in nuova scheda o salvarla e aprirla in un visualizzatore di immagini.

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 Edge 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 Edge per recuperare l'ID e le chiavi secret del client. 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 Edge, 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 Apigee Edge

Se l'accesso e il consenso hanno esito positivo, l'app di accesso PUBBLICA i dati in /Authorizationcode di Apigee Edge. 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 Edge genera un codice di autorizzazione

Quando Edge riceve una richiesta GET dall'app di accesso sul proprio endpoint /permissioncode, vengono succedono cose. Innanzitutto, Edge determina che l'accesso è riuscito (controllando lo stato HTTP o in altri modi). Next Edge 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 Edge. Se è tutto a posto, Edge 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. Dispositivi periferici restituisce il codice di autorizzazione al client

Edge invia un reindirizzamento 302 con il codice di autorizzazione collegato come parametro di query alla di alto profilo.

7. Il client recupera il codice di autorizzazione e richiede un codice di accesso a Edge

Ora con un codice di autorizzazione valido, il client può richiedere un token di accesso a Edge. Per farlo, POSTando l'ID client e le chiavi secret del client (ottenute al momento della registrazione dell'app su Edge), tipo di autorizzazione e ambito. Includendo l'ID client e le chiavi secret, Apigee Edge 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 funziona correttamente, Edge 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 effettuate ad Apigee Edge (il proxy), che è responsabile della 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 quanto server di autorizzazione, Edge 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 ogni passaggio o "gamba" del flusso sia definita da un flusso nel proxy Apigee Edge. 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 denominato 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.

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 di callout dei servizi, JavaScript, Node.js o in altri modi.

La chiamata API per eseguire la richiesta è GET e richiede i parametri di query 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 query 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, Grants_type=authorization_code e, facoltativamente, l'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 (criteri 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. Edge controlla che ogni richiesta abbia un 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.