Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione
Documentazione di Apigee X. Informazioni
Con il tipo di concessione delle credenziali client, un'app invia le proprie credenziali (ID client e client secret) a un endpoint su Apigee Edge configurato per generare un token di accesso. Se siano valide, Edge restituisce un token di accesso all'app client.
Informazioni su questo argomento
Questo argomento offre una descrizione generale del tipo di concessione delle credenziali client OAuth 2.0 e illustra come implementare questo flusso su Apigee Edge.
Casi d'uso
Di solito, questo tipo di autorizzazione viene utilizzato quando l'app è anche il proprietario della risorsa. Ad esempio: un'app potrebbe aver bisogno di accedere a un servizio di archiviazione backend basato su cloud per archiviare e recuperare i dati che utilizza per svolgere le proprie attività, anziché dati di proprietà specifica dell'utente finale. Questo tipo di concessione avviene rigorosamente tra un'app client e il server di autorizzazione. Un utente finale non a questo flusso di tipi di concessioni.
Ruoli
I ruoli specificano gli "attori" che partecipano al flusso OAuth. Facciamo una rapida panoramica i ruoli delle credenziali client per illustrare dove si inserisce Apigee Edge. Per un per la discussione sui ruoli di OAuth 2.0, consulta la specifica OAuth 2.0 di IETF.
- App client: l'app che deve accedere al profilo Google Cloud. In genere, con questo flusso, l'app viene eseguita sul server e non localmente su un laptop o un dispositivo.
- Apigee Edge: in questo flusso, Apigee Edge è server web. Il suo ruolo è generare i token di accesso, convalidare i token di accesso e passare le autorizzazioni per le risorse protette sul server delle risorse.
- Server di risorse: il servizio di backend che archivia i dati protetti a cui l'app client necessita dell'autorizzazione per accedere. Se stai proteggendo i proxy API ospitati su Apigee Edge, quindi Apigee Edge, è anche il server di risorse.
Esempio di codice
Puoi trovare un completo e funzionante di esempio del tipo di concessione delle credenziali client su GitHub. Consulta la sezione Risorse aggiuntive di seguito per i link ad altri esempi.
Diagramma di flusso
Il seguente diagramma di flusso illustra il flusso delle credenziali client con Apigee Edge utilizzato come il server di autorizzazione. In generale, Edge è anche il server di risorse in questo flusso, ovvero I proxy API sono le risorse protette.
Passaggi nel flusso delle credenziali client
Ecco un riepilogo dei passaggi necessari per implementare il tipo di concessione del codice delle credenziali client in cui Apigee Edge funge da server di autorizzazione. Ricorda che, con questo flusso, l'app client presenta semplicemente il proprio ID client e il proprio client secret e, se sono validi, Apigee Edge restituisce token di accesso.
Prerequisito: l'app client deve essere registrata con Apigee Edge per ottenere l'ID client e le chiavi secret del client. Consulta Registrazione di app client per i dettagli.
1. Il client richiede un token di accesso
Per ricevere un token di accesso, il client POSTA una chiamata API a Edge con i valori per l'ID client e client secret ottenuti da un'app sviluppatore registrata. Inoltre, il parametro concessi_type=client_credentials devono essere passati come parametro di query. (Tuttavia, puoi configurare il criterio OAuthV2 per accettare questo parametro nell'intestazione o nel corpo della richiesta. Consulta Criterio OAuthV2 per i dettagli.
Ad esempio:
$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials&client_id=ns4fQc14Zg4hKFCNaSzArVuwszX95X&client_secret=ZIjFyTsNgQNyxI'
Nota:anche se puoi passare i valori client_id e client_secret come query come mostrato sopra, è buona norma trasmetterli come stringa con codifica URL base64 l'intestazione Autorizzazione. Per farlo, è necessario utilizzare uno strumento di codifica Base64 o un'utilità per codificare i due valori insieme ai due punti che li separano. Ad esempio: aBase64EncodeFunction(valoreIDclient:segreto client). Quindi, l'esempio precedente sarebbe codificato come questo:
result = aBase64EncodeFunction(ns4fQc14Zg4hKFCNaSzArVuwszX95X:ZIjFyTsNgQNyxI) // Nota la due punti che separano i due valori.
Il risultato della codifica in base64 della stringa precedente è: bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg==
Quindi, effettua la richiesta di token nel seguente modo:
$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials' -H 'Authorization: Basic bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg=='
2. Edge convalida credenziali
Tieni presente che la chiamata API viene inviata all'endpoint /accesstoken. Questo endpoint ha un criterio che convalida le credenziali dell'app. In altre parole, le norme confrontano con quelle create da Apigee Edge al momento della registrazione dell'app. Se desideri Per saperne di più sugli endpoint OAuth su Edge, consulta Configurazione di OAuth endpoint e criteri.
3. Edge restituisce una risposta
Se le credenziali sono corrette, Edge restituisce un token di accesso al client. In caso contrario, viene visualizzato un errore restituito.
4. Il cliente chiama API Protected
Ora, con un token 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. Ad esempio, consulta la sezione Chiamare l'API protetta di seguito.
Configurazione di flussi e criteri
In qualità di server di autorizzazione, Edge elabora le richieste per i token di accesso. In qualità di sviluppatore dell'API, devi creare un proxy con un flusso personalizzato per gestire le richieste di token, aggiungere Criterio OAuthV2. Questa sezione spiega come configurare l'endpoint.
Configurazione del flusso personalizzato
Il modo più semplice per mostrare come è configurato il flusso proxy API è mostrare il flusso XML definizione di Kubernetes. Ecco un esempio di flusso di proxy API progettato per elaborare una richiesta di token di accesso. Per Ad esempio, quando arriva una richiesta e il suffisso del percorso corrisponde a /accesstoken, il valore viene attivato. Consulta la sezione Configurazione di OAuth. endpoint e criteri per una rapida panoramica dei passaggi necessari per creare un flusso personalizzato in questo modo.
<Flows>
<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>GetAccessToken</Name></Step>
</Request>
</Flow>
</Flows>
Configurare il flusso con un criterio
Devi collegare un criterio all'endpoint, come segue. Consulta la sezione Configurazione di OAuth. endpoint e criteri per una rapida panoramica dei passaggi necessari per aggiungere un criterio OAuthV2. a un endpoint proxy.
Richiedi token di accesso
Questo criterio è collegato al percorso /accesstoken. Utilizza il protocollo OAuthV2
specificato con l'operazione GeneraAccessToken specificata.
<OAuthV2 name="GetAccessToken">
<Operation>GenerateAccessToken</Operation>
<ExpiresIn>3600000</ExpiresIn>
<SupportedGrantTypes>
<GrantType>client_credentials</GrantType>
</SupportedGrantTypes>
<GenerateResponse/>
</OAuthV2>
La chiamata API per ottenere il token di accesso è di tipo POST e include un’intestazione Autorizzazione con il client_id codificato in base64 + client+secret e il parametro di query grant_type=client_credentials. Può anche includere parametri facoltativi per ambito e stato. Per esempio:
$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials' -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVgT1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ'
Collegamento del criterio di verifica del token di accesso in corso...
Per proteggere l'API con la sicurezza OAuth 2.0, devi aggiungere un criterio OAuthV2 con la Operazione VerifyAccessToken. Questo criterio controlla che le richieste in entrata abbiano un token di accesso valido. Se il token è valido, Edge elabora la richiesta. Se non è valido, Edge restituisce un errore. Per i passaggi di base, consulta la sezione Verificare di accesso ai token.
<OAuthV2 async="false" continueOnError="false" enabled="true" name="VerifyAccessToken">
<DisplayName>VerifyAccessToken</DisplayName>
<ExternalAuthorization>false</ExternalAuthorization>
<Operation>VerifyAccessToken</Operation>
<SupportedGrantTypes/>
<GenerateResponse enabled="true"/>
<Tokens/>
</OAuthV2>
Chiamare l'API Protected
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 Inviare un accesso di accesso.
Risorse aggiuntive
- Apigee offre formazione online per sviluppatori di API, tra cui un corso su API sicurezza, compreso OAuth.
- Criterio OAuthV2 -- Contiene molti esempi che mostrano come effettuare richieste al server di autorizzazione e come configurare il criterio OAuthV2.