Implementazione del tipo di concessione della password

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Il tipo di concessione 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 di risorse (nome utente/password) all'app client, che le invia in una richiesta di token di accesso ad Apigee. Un server di identità convalida le credenziali e, se sono valide, Apigee procede a creare un token di accesso e lo restituisce all'app.

Informazioni su questo argomento

Questo argomento fornisce una descrizione generale e una panoramica del flusso del tipo di concessione della password del proprietario delle risorse OAuth 2.0 e illustra come implementare questo flusso su Apigee.

Esempi che potrebbero esserti utili

  • Utilizzare il tipo di concessione della password: mostra come creare una richiesta di token, configurare il criterio OAuthV2 per il tipo di concessione della password e come configurare un endpoint per il criterio in Apigee.
  • oauth-validate-key-secret: un proxy di esempio su GitHub che puoi eseguire in Apigee e provare. Si tratta di un esempio end-to-end che mostra il tipo di concessione della password. Mostra una best practice, ovvero l'autenticazione delle 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 concessione della password.

Casi d'uso

Questo tipo di concessione è destinato ad app altamente attendibili o privilegiate perché l'utente deve fornire le credenziali del server di risorse all'app. In genere, l'app fornisce una schermata di accesso in cui l'utente inserisce le credenziali.

Diagramma di flusso

Il seguente diagramma di flusso illustra il flusso del tipo di concessione della password del proprietario della risorsa con Apigee come server di autorizzazione.

Suggerimento:per visualizzare una versione più grande di questo diagramma, fai clic con il tasto destro del mouse e apri il diagramma in una nuova scheda oppure salvalo e apri in un visualizzatore di immagini.

Il flusso del tipo di concessione della password del proprietario della risorsa.

Passaggi della procedura di tipo di concessione della password

Di seguito è riportato un riepilogo dei passaggi necessari per implementare il tipo di concessione con password in cui Apigee funge da server di autorizzazione.

Prerequisito: l'app client deve essere registrata in Apigee per ottenere le chiavi dell'ID client e del 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, 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 GenerateAccessToken su Apigee.

Ecco una richiesta POST di esempio, che include i parametri richiesti 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, il comando può essere eseguito come segue, utilizzando l'opzione -u per curl per creare l'intestazione di autenticazione di base con codifica 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 essere su una riga sola).

Le credenziali utente sono contenute nei parametri del modulo, mentre le credenziali client sono codificate nell'intestazione per autenticazione di base HTTP. Per una descrizione dettagliata di questa chiamata API, tra cui i dettagli sull'intestazione di autenticazione di base richiesta, consulta la sezione relativa alla concessione della password di "Ottenere token OAuth 2.0".

3. Apigee convalida l'app del cliente

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 attendibile e valida. Un modo per farlo è utilizzare l'autenticazione della chiave API nella chiamata API. In alcuni casi, potresti voler convalidare sia la chiave sia il secret del client. Esiste un proxy di esempio che illustra questa tecnica alternativa nel repository api-platform-samples su GitHub.

4. Apigee elabora le credenziali di accesso

Dopo la convalida dell'app client, puoi utilizzare un callout del servizio o un criterio JavaScript per chiamare il servizio di identità inviando le credenziali dell'utente. Ad esempio, potrebbe essere un servizio LDAP o qualsiasi servizio che vuoi utilizzare per convalidare le credenziali. Per informazioni dettagliate su queste norme, consulta le norme relative alle variabili estruse e le norme relative a 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. Viene eseguito il criterio OAuthV2

Se le credenziali sono valide, il passaggio di elaborazione successivo consiste nell'eseguire un criterio OAuthV2 configurato per il tipo di concessione 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 queste norme, consulta le norme di 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 questo criterio 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 inviate ad Apigee (il proxy) e Apigee è responsabile della convalida del token di accesso prima di inoltrare 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