Questa pagina si applica ad Apigee e Apigee hybrid.
Visualizza la documentazione di
Apigee Edge.
Il tipo di autorizzazione della password del proprietario della risorsa (o "password") viene utilizzato principalmente nei casi in cui l'app è molto attendibile. In questa configurazione, l'utente fornisce le credenziali del server delle risorse (nome utente/password) all'app client, che lo invia ad Apigee in una richiesta di token di accesso. Un server di identità convalida le credenziali e, se sono valide, Apigee procede al mining 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 autorizzazione del proprietario delle risorse OAuth 2.0 e illustra come implementare questo flusso su Apigee.
Esempi che potrebbero esserti utili
- Utilizza il tipo di autorizzazione della password: mostra come creare una richiesta di token, configurare il criterio OAuthV2 per il tipo di autorizzazione della password e come configurare un endpoint per il criterio in Apigee.
- oauth-validate-key-secret: un proxy di esempio in GitHub di cui puoi eseguire il deployment su Apigee e provare. Si tratta di un esempio end-to-end con il tipo di autorizzazione della password. Dimostra una best practice, cioè autenticare le credenziali dell'app client (chiave/segreto) prima di inviare le credenziali dell'utente a un provider di identità.
Video
Video: guarda questo video sull'implementazione del tipo di autorizzazione della password.
Casi d'uso
Questo tipo di autorizzazione è destinato alle app altamente affidabili o con privilegi perché l'utente deve fornire all'app le credenziali del server delle risorse. 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 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 tipo di concessione della password
Ecco un riepilogo dei passaggi necessari per implementare il tipo di concessione della password in cui Apigee funge da server di autorizzazione.
Prerequisito:l'app client deve essere registrata con Apigee per ottenere l'ID client e le chiavi client secret. Per maggiori dettagli, consulta Registrazione delle app client.
1. L'utente avvia il flusso e inserisce le credenziali
Quando l'app deve accedere alle risorse protette dell'utente (ad esempio quando l'utente fa clic su un pulsante nell'app), l'utente viene reindirizzato a un modulo di accesso.
2. L'app richiede un token di accesso da Apigee
L'app invia una richiesta di token di accesso, incluse le credenziali dell'utente, a un endpoint GeneraAccessToken su Apigee.
Ecco un esempio di richiesta POST, che include i parametri richiesti per questo tipo di autorizzazione:
$ 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, il comando può essere eseguito come segue, utilizzando l'opzione -u per curl per creare automaticamente 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
(ognuno di questi comandi deve trovarsi tutti 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 Autorizzazione di base richiesta, consulta la sezione relativa all'autorizzazione della password in "Ottenere token OAuth 2.0".
3. Apigee 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 del client sia il secret. Esiste un proxy di esempio che illustra questa tecnica di allternate nel repository api-platform-samples su GitHub.
4. Apigee elabora le credenziali di accesso
Dopo la convalida dell'app client, puoi utilizzare un criterio JavaScript o callout di servizio 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 maggiori dettagli su questi criteri, consulta il criterio Estrai variabili e il Criterio JavaScript.
Se il servizio di identità convalida le credenziali e restituisce una risposta 200, Apigee continuerà a elaborare la richiesta; in caso contrario, Apigee interrompe l'elaborazione e restituisce un errore all'app client.
5. Il criterio OAuthV2 viene eseguito
Se le credenziali sono valide, il passaggio di elaborazione successivo prevede l'esecuzione di un criterio OAuthV2 configurato per il tipo di autorizzazione della password. Ecco un esempio. Gli elementi <UserName> e <PassWord> sono obbligatori e puoi recuperarli dalle variabili di flusso salvate con il criterio ExtractVariables. Per informazioni di riferimento dettagliate su questo criterio, consulta il criterio 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 il criterio ha esito positivo, al client viene generata una risposta 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 (il proxy), che è responsabile 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 I6daIgMSiUgYX1K2qgQWPi37ztS6
" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282