Stai visualizzando la documentazione di Apigee Edge.
Consulta la
documentazione di Apigee X. info
Il tipo di concessione della password del proprietario della risorsa (o "password") viene utilizzato principalmente nei casi in cui l'app è altamente attendibile. In questa configurazione, l'utente fornisce le credenziali del server di risorse (nome utente/password) all'app client, che le invia in una richiesta di token di accesso ad Apigee Edge. Un server di identità convalida le credenziali e, se sono valide, Edge procede alla creazione di un token di accesso e lo restituisce all'app.
Informazioni su questo argomento
Questo argomento offre una descrizione generale e una panoramica del flusso del tipo di concessione della password del proprietario della risorsa OAuth 2.0 e spiega come implementare questo flusso su Apigee Edge.
Esempi che potrebbero esserti utili
- Richiesta di un token di accesso: tipo di concessione della password: mostra come formare una richiesta di token, configurare la policy OAuthV2 per il tipo di concessione della password e come configurare un endpoint per la policy in Edge.
- oauth-validate-key-secret: un proxy di esempio su GitHub che puoi eseguire il deployment su Edge e provare È un esempio end-to-end che include il tipo di concessione della password. Dimostra una best practice, ovvero autenticare le credenziali (chiave/secret) dell'app client prima di inviare le credenziali dell'utente a un provider di identità.
Video
Video: guarda questo video sull'implementazione del tipo di concessione della password.
Casi d'uso
Questo tipo di concessione è destinato ad app altamente attendibili o con privilegi, perché l'utente è tenuto a fornire le credenziali del server di risorse all'app. In genere, l'app fornisce una schermata di accesso in cui l'utente inserisce le proprie credenziali.
Diagramma di flusso
Il seguente diagramma di flusso illustra il flusso del tipo di concessione della password del proprietario della risorsa 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 del flusso del tipo di concessione della password
Di seguito è riportato un riepilogo dei passaggi necessari per implementare il tipo di concessione della password in cui Apigee Edge funge da server di autorizzazione.
Prerequisito: l'app client deve essere registrata con Apigee Edge per ottenere le chiavi ID client e client secret. Per maggiori dettagli, consulta Registrare le app client per dettagli.
1. L'utente avvia il flusso e inserisce le credenziali
Quando l'app deve accedere alle risorse protette dell'utente (ad esempio, l'utente fa clic su un pulsante nell'app), viene reindirizzato a un modulo di accesso.
2. L'app richiede un token di accesso ad Apigee Edge
L'app invia una richiesta di token di accesso, incluse le credenziali dell'utente, a un endpoint GenerateAccessToken su Apigee Edge.
Di seguito è riportata una richiesta POST di esempio, che include i parametri obbligatori per questo tipo di concessione:
$ curl -i \ -X POST \ -H 'Content-Type: application/x-www-form-urlencoded' \ -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \ -d 'grant_type=password&username=the-user-name&password=the-users-password' \ https://docs-test.apigee.net/oauth/token
In alternativa, questo comando può essere eseguito come segue, utilizzando l'opzione -u di curl per creare l'intestazione di autenticazione di base codificata in base64.
$ curl -i \ -X POST \ -H 'Content-Type: application/x-www-form-urlencoded' \ -u sqH8ooHexTz8C02IX9ORo6rhgq1iSrAl:Z4ljtJdneBOjPMAU \ -d 'grant_type=password&username=the-user-name&password=the-users-password' \ https://docs-test.apigee.net/oauth/token
(Ciascuno di questi comandi deve essere su una sola riga.)
Le credenziali utente sono contenute nei parametri del modulo, mentre le credenziali client sono codificate nell'intestazione di autenticazione di base HTTP. Per una descrizione dettagliata di questa chiamata API, inclusi i dettagli sull'intestazione di autenticazione di base obbligatoria, consulta la sezione relativa alla concessione della password in "Richiedere token di accesso e codici di autorizzazione".
3. Edge convalida l'app client
Prima di inviare il nome utente e la password dell'utente a un provider di identità, Edge deve sapere che l'app client che effettua la richiesta è un'app valida e attendibile. Un modo per farlo è utilizzare l'autenticazione con chiave API nella chiamata API. In alcuni casi, potresti voler convalidare sia la chiave client sia il secret. Nel repository api-platform-samples su GitHub è disponibile un proxy di esempio che illustra questa tecnica alternativa.
4. Edge elabora le credenziali di accesso
Dopo aver convalidato l'app client, puoi utilizzare una policy Service Callout o JavaScript per chiamare il servizio di identità, inviando le credenziali dell'utente. Ad esempio, potrebbe trattarsi di un servizio LDAP o di qualsiasi servizio che vuoi utilizzare per convalidare le credenziali. Per informazioni dettagliate su queste policy, consulta Policy Estrai variabili e Policy JavaScript.
Se il servizio di identità convalida le credenziali e restituisce una risposta 200, Edge continuerà a elaborare la richiesta; in caso contrario, Edge interromperà l'elaborazione e restituirà un errore all' app client.
5. Viene eseguita la policy OAuthV2
Se le credenziali sono valide, il passaggio di elaborazione successivo consiste nell'eseguire una policy OAuthV2 configurata per il tipo di concessione della password. Ecco un esempio. Gli elementi <UserName> e <PassWord> sono obbligatori e puoi recuperarli dalle variabili di flusso che sono state salvate con la policy ExtractVariables. Per informazioni di riferimento dettagliate su questa policy, consulta Policy OAuthV2.
<OAuthV2 name="GetAccessToken"> <Operation>GenerateAccessToken</Operation> <ExpiresIn>360000000</ExpiresIn> <SupportedGrantTypes> <GrantType>password</GrantType> </SupportedGrantTypes> <GrantType>request.queryparam.grant_type</GrantType> <UserName>login</UserName> <PassWord>password</PassWord> <GenerateResponse/> </OAuthV2>
Se questa policy ha esito positivo, viene generata una risposta al client contenente un token di accesso. La risposta è in formato JSON. Ecco un esempio. Tieni presente che access_token è uno degli elementi:
{ "issued_at": "1420258685042", "scope": "READ", "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b", "refresh_token_issued_at": "1420258685042", "status": "approved", "refresh_token_status": "approved", "api_product_list": "[PremiumWeatherAPI]", "expires_in": "1799", "developer.email": "tesla@weathersample.com", "organization_id": "0", "token_type": "BearerToken", "refresh_token": "IFl7jlijYuexu6XVSSjLMJq8SVXGOAAq", "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT", "access_token": "I6daIgMSiUgYX1K2qgQWPi37ztS6", "organization_name": "docs", "refresh_token_expires_in": "0", "refresh_count": "0" }
6. 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) ed Edge è responsabile della convalida del token di accesso prima di passare la chiamata API al server di risorse di destinazione. I token di accesso vengono passati in un'intestazione Authorization. Ad esempio:
$ curl -H "Authorization: Bearer I6daIgMSiUgYX1K2qgQWPi37ztS6 " http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282