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 documentazione di Apigee X. informazioni

Il codice di autorizzazione è uno dei tipi di autorizzazione OAuth 2.0 più utilizzati. Il flusso del codice di autorizzazione è una configurazione "OAuth a tre vie". In questa configurazione, l'utente si 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 flusso del tipo di concessione dell'autorizzazione OAuth 2.0 e illustra come implementare questo flusso 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 concessione è destinato alle app scritte da sviluppatori di terze parti che non hanno un rapporto commerciale affidabile con il fornitore dell'API. Ad esempio, generalmente gli sviluppatori che si registrano a programmi API pubblici non dovrebbero essere considerati attendibili. Con questo tipo di autorizzazione, le credenziali dell'utente sul server delle risorse non vengono mai condivise con l'app.

Esempio di codice

Puoi trovare un'implementazione di esempio completa e funzionante del tipo di concessione del codice di autorizzazione su Apigee Edge nel repository api-platform-samples su GitHub. Visualizza l'esempio di oauth-advanced nella directory api-platform-samples/sample-proxies. Consulta il file README per i dettagli sull'esempio.

Diagramma di flusso

Il seguente diagramma di flusso illustra il flusso OAuth del codice di autorizzazione con Apigee Edge che funge da server di autorizzazione.

Suggerimento: per visualizzare una versione più grande di questo diagramma, fai clic con il tasto destro del mouse e aprilo in una nuova scheda oppure salvalo e aprilo 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 riesce mai a vedere le credenziali dell'utente sul server delle risorse.

Prerequisito: l'app client deve essere registrata con Apigee Edge per ottenere l'ID client e le chiavi client secret. Per maggiori dettagli, consulta Registrazione delle app client.

1. L'utente avvia il flusso

Quando l'app deve accedere alle risorse protette dell'utente da un server di risorse (ad esempio, un elenco di contatti su un sito di social media), invia una chiamata API ad Apigee Edge, che convalida l'ID del client e, se è valida, reindirizza il browser dell'utente a una pagina di accesso in cui l'utente inserirà le proprie credenziali. La chiamata API include le informazioni ottenute dall'app client al momento della registrazione: l'ID client e l'URI di reindirizzamento.

2. L'utente inserisce le credenziali

Ora l'utente vede una pagina di accesso in cui viene chiesto di inserire le credenziali di accesso. Se l'accesso viene eseguito correttamente, vai al passaggio successivo.

3. L'utente dà il consenso

In questo passaggio, l'utente concede all'app il consenso ad accedere alle sue risorse. In genere, il modulo di consenso include selezioni di ambiti, in cui l'utente può scegliere cosa può fare l'app sul server delle risorse. Ad esempio, l'utente potrebbe concedere l'autorizzazione di sola lettura o l'autorizzazione all'app per aggiornare le risorse.

4. L'app di accesso invia una richiesta ad Apigee Edge

Se l'accesso e il consenso hanno esito positivo, l'app di accesso invia i dati all'endpoint /Authorizationcode di Apigee Edge. I dati includono URI di reindirizzamento, ID client, ambito, eventuali informazioni specifiche dell'utente 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 suo endpoint /Authorizationcode, si verificano due cose. Innanzitutto, Edge determina che l'accesso è riuscito (controllando lo stato HTTP o altri mezzi). Next Edge controlla che l'URI di reindirizzamento inviato dall'app di accesso corrisponda a quello specificato al momento della registrazione dell'app con Apigee Edge. Se non ci sono problemi, 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. Edge invia il codice di autorizzazione al client

Edge invia al client un reindirizzamento 302 con il codice di autenticazione associato come parametro di query.

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

Ora con un codice di autorizzazione valido, il client può richiedere un token di accesso da Edge. A questo scopo, PUBBLICA l'ID client e le chiavi client secret (ottenute al momento della registrazione dell'app su Edge), il tipo di autorizzazione e l'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 client riceve un token di accesso

Se tutto funziona correttamente, Edge restituisce un token di accesso al client. Il token di accesso avrà una scadenza e sarà valido solo per l'ambito specificato dall'utente quando ha acconsentito all'app per accedere alle proprie risorse.

9. Il client chiama l'API protetta

Ora, con un codice di accesso valido, il client può effettuare chiamate all'API protetta. In questo scenario, le richieste vengono effettuate ad Apigee Edge (il proxy), che si occupa della convalida del token di accesso prima di passare la chiamata API al server delle risorse di destinazione. I token di accesso vengono passati in un'intestazione di 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, Edge deve elaborare una serie di richieste OAuth: per token di accesso, codici di autorizzazione, token di aggiornamento, reindirizzamenti alle pagine di accesso e così via, la configurazione di questi endpoint prevede due passaggi fondamentali:

Creazione di flussi personalizzati
Aggiunta e configurazione di criteri OAuthV2

Configurazione dei flussi personalizzata

In genere, questo flusso di tipo di autorizzazione viene configurato in modo che ogni passaggio o "tratto" del flusso sia definito da un flusso nel proxy Apigee Edge. Ogni flusso ha un endpoint e un criterio che esegue l'attività specifica per OAuth richiesta, ad esempio la generazione di un codice di autorizzazione o di un token di accesso. Ad esempio, come mostrato nel codice XML di seguito, all'endpoint /oauth/authorizationcode è associato un criterio chiamato GeneraAuthCode (che è un criterio OAuthV2 con l'operazione GeneraAuthorizationCode specificata).

Il modo più semplice per mostrare la configurazione del flusso è con un esempio XML. Consulta i commenti in linea per informazioni su ciascun flusso. Questo è un esempio: i nomi dei flussi e dei percorsi possono essere configurati come preferisci. Vedi anche Configurazione di endpoint e criteri OAuth per una rapida panoramica dei passaggi necessari per creare un flusso personalizzato come questo.

Vedi anche l'implementazione di esempio 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 delle norme. Consulta anche la pagina relativa alla configurazione di endpoint e criteri OAuth per una rapida panoramica dei passaggi necessari per aggiungere i criteri OAuthV2 agli endpoint del proxy.

Questo è il percorso /oauth/authorize. Il criterio allegato è responsabile del reindirizzamento dell'utente a un'app di accesso, dove l'utente finale può autenticare e autorizzare in modo sicuro l'app client ad accedere alle risorse protette senza divulgare nome utente e password all'app client. A questo scopo, puoi utilizzare un criterio di callout del servizio, JavaScript, Node.js o altro.

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 l'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 è una richiesta 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}

Recupera token di accesso

Questo criterio è collegato al percorso /oauth/accesstoken. Utilizza il criterio OAuthV2 con l'operazione GeneraAccessCode specificata. In questo caso, è previsto il parametro allow_type 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 è una richiesta POST e deve includere client_id, client_secret, Grants_type=permissions_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 la creazione di URL, l'esecuzione di trasformazioni e altre attività. Fai riferimento all'esempio su GitHub per un progetto completo e funzionante.

Collegamento del criterio del token di accesso di verifica

Collega un criterio VerificationAccessToken (criterio OAuthV2 con l'operazione VerificationAccessToken specificata) all'inizio di qualsiasi flusso che accede a un'API protetta, in modo che venga eseguito ogni volta che riceve 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, consulta 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 token di accesso valido. Il pattern corretto prevede l'inclusione del token in un'intestazione di autorizzazione, come segue: tieni presente che il token di accesso è denominato anche "token di trasferimento".

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

Vedi anche Inviare un token di accesso.