Implementazione del tipo di concessione del codice di autorizzazione

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 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.

Nota: visualizza una versione più grande di questo diagramma.

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.

Nota: le illustrazioni riportate di seguito sono tratte dall'account di autorizzazione di esempio di codice su GitHub.

Prerequisito: l'app client deve essere registrata con Apigee per recuperare l'ID e le chiavi 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.

Nota: è importante notare che l'app client non vede mai questi dati informazioni. Viene gestito lato server e negoziato tra l'app di accesso e Apigee. Per per vedere un esempio che mostra come questo passaggio viene gestito in modo sicuro, fai riferimento alla un'implementazione di esempio di codice su GitHub.

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), il tipo di autorizzazione e l'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 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.

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}

Best practice: l'app di accesso in genere PUBBLICA una risposta di reindirizzamento e torniamo ad Apigee. Apigee indirizza quindi il browser dell'utente all'URL di callback registrato. È un best practice per non inviare la risposta direttamente allo user agent/client per evitare di esporre informazioni sensibili. L'URL di callback viene definito durante la registrazione di un'app sul Portale per gli sviluppatori o utilizzando l'API Developer Apps

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, 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. 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.