Stai visualizzando la documentazione di Apigee Edge.
Consulta la
documentazione di Apigee X. info
Con il tipo di concessione delle credenziali client, un'app invia le proprie credenziali (ID client e client secret) a un endpoint di Apigee Edge configurato per generare un token di accesso. Se le credenziali sono 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 spiega come implementare questo flusso su Apigee Edge.
Casi d'uso
In genere, questo tipo di concessione viene utilizzato quando l'app è anche il proprietario della risorsa. Ad esempio, un'app potrebbe dover accedere a un servizio di archiviazione basato sul cloud di backend per archiviare e recuperare i dati che utilizza per svolgere il proprio lavoro, anziché i dati di proprietà specifica dell'utente finale. Questo flusso di tipo di concessione si verifica rigorosamente tra un'app client e il server di autorizzazione. Un utente finale non partecipa a questo flusso di tipo di concessione.
Ruoli
I ruoli specificano gli "attori" che partecipano al flusso OAuth. Diamo una rapida occhiata ai ruoli delle credenziali client per illustrare dove si inserisce Apigee Edge. Per una discussione completa dei ruoli OAuth 2.0, consulta la specifica IETF OAuth 2.0.
- App client : l'app che deve accedere alle risorse protette dell'utente. In genere, con questo flusso, l'app viene eseguita sul server anziché localmente sul laptop o sul dispositivo dell'utente.
- Apigee Edge : in questo flusso, Apigee Edge è il server di autorizzazione OAuth server. Il suo ruolo è generare token di accesso, convalidare i token di accesso e inoltrare le richieste autorizzate per le risorse protette al server di risorse.
- Server di risorse : il servizio di backend che archivia i dati protetti a cui l'app client deve avere l'autorizzazione per accedere. Se proteggi i proxy API ospitati su Apigee Edge, Apigee Edge è anche il server di risorse.
Esempio di codice
Puoi trovare un'implementazione di esempio completa e funzionante del tipo di concessione delle credenziali client su GitHub. Per i link ad altri esempi, vedi Risorse aggiuntive di seguito.
Diagramma di flusso
Il seguente diagramma di flusso illustra il flusso delle credenziali client con Apigee Edge che funge da server di autorizzazione. In generale, in questo flusso Edge è anche il server di risorse, ovvero i proxy API sono le risorse protette.
Passaggi del flusso delle credenziali client
Di seguito è riportato 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 l'ID client e il client secret e, se sono validi, Apigee Edge restituisce un token di accesso.
Prerequisito: l'app client deve essere registrata con Apigee Edge per ottenere le chiavi ID client e client secret. Per informazioni dettagliate, vedi Registrare le app client per dettagli.
1. Il client richiede un token di accesso
Per ricevere un token di accesso, il client invia una chiamata API a Edge con i valori di ID client e client secret ottenuti da un'app sviluppatore registrata. Inoltre, il parametro grant_type=client_credentials deve essere passato come parametro di query. (Tuttavia, puoi configurare la policy OAuthV2 in modo che accetti questo parametro nell'intestazione della richiesta o nel corpo della richiesta. Per informazioni dettagliate, vedi policy OAuthV2).
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 parametri di query come mostrato sopra, è consigliabile passarli come stringa con codifica URL base64 nell'intestazione Authorization. Per farlo, devi utilizzare uno strumento o un'utilità di codifica base64 per codificare i due valori insieme al punto e virgola che li separa. Ad esempio: aBase64EncodeFunction(clientidvalue:clientsecret). Quindi, l'esempio precedente verrebbe codificato come segue:
result = aBase64EncodeFunction(ns4fQc14Zg4hKFCNaSzArVuwszX95X:ZIjFyTsNgQNyxI) // Note the colon separating the two values.
Il risultato della codifica base64 della stringa precedente è: bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg==
Quindi, effettua la richiesta di token come segue:
$ 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 le credenziali
Tieni presente che la chiamata API viene inviata all'endpoint /accesstoken. A questo endpoint è associata una policy che convalida le credenziali dell'app. Ovvero, la policy confronta le chiavi inviate con quelle create da Apigee Edge durante la registrazione dell'app. Per saperne di più sugli endpoint OAuth su Edge, vedi Configurare endpoint e policy OAuth.
3. Edge restituisce una risposta
Se le credenziali sono corrette, Edge restituisce un token di accesso al client. In caso contrario, viene restituito un errore.
4. Il client chiama l' API protetta
Ora, con un token di accesso valido, il client può effettuare chiamate all'API protetta. In questo scenario, le richieste vengono effettuate ad Apigee Edge (il proxy) ed Edge è responsabile della convalida del token di accesso prima di inoltrare la chiamata API al server di risorse di destinazione. Per un esempio, vedi Chiamare l'API protetta di seguito.
Configurare flussi e policy
In qualità di server di autorizzazione, Edge elabora le richieste di token di accesso. In qualità di sviluppatore di API, devi creare un proxy con un flusso personalizzato per gestire le richieste di token e aggiungere e configurare una policy OAuthV2. Questa sezione spiega come configurare l'endpoint.
Configurazione del flusso personalizzato
Il modo più semplice per mostrare come viene configurato il flusso del proxy API è mostrare la definizione del flusso XML. Ecco un esempio di flusso di proxy API progettato per elaborare una richiesta di token di accesso. Ad esempio, quando arriva una richiesta e il suffisso del percorso corrisponde a /accesstoken, viene attivata la policy GetAccessToken. Per una rapida panoramica dei passaggi necessari per creare un flusso personalizzato come questo, vedi Configuring OAuth endpoint e policy.
<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 una policy
Devi collegare una policy all'endpoint, come segue. Per una rapida panoramica dei passaggi necessari per aggiungere una policy OAuthV2 a un endpoint proxy, vedi Configurare endpoint e policy OAuth.
Ottenere il token di accesso
Questa policy è collegata al percorso /accesstoken. Utilizza la policy OAuthV2
con l'operazione GenerateAccessToken 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 è un POST e include un'intestazione Authorization con client_id + client+secret con codifica base64 e il parametro di query grant_type=client_credentials. Può includere anche parametri facoltativi per scope e state. 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' -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVgT1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ'
Collegare la policy di verifica del token di accesso
Per proteggere l'API con la sicurezza OAuth 2.0, devi aggiungere una policy OAuthV2 con l'operazione VerifyAccessToken. Questa policy verifica 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, 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>Chiamare l'API protetta
Per chiamare un'API protetta con la sicurezza OAuth 2.0, devi presentare un token di accesso valido. Il pattern corretto consiste nell'includere il token in un'intestazione Authorization, come segue: tieni presente che il token di accesso è anche chiamato "token di autenticazione".
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
Vedi anche Inviare un token di accesso.
Risorse aggiuntive
- Apigee offre corsi di formazione online per gli sviluppatori di API, tra cui un corso sulla sicurezza delle API, che include OAuth.
- Policy OAuthV2: contiene molti esempi che mostrano come effettuare richieste al server di autorizzazione e come configurare la policy OAuthV2.