Questa pagina si applica a Apigee e Apigee ibridi.
Visualizza
documentazione di Apigee Edge.
Il tipo di autorizzazione della password del proprietario della risorsa (o "password") viene usato principalmente nei casi in cui l'app è molto affidabile. In questa configurazione, l'utente fornisce le credenziali del proprio server di risorse (nome utente/password) all'app client, che li invia in una richiesta di token di accesso ad Apigee. Un server di identità convalida le credenziali e, se sono valide, Apigee passa al mint un token di accesso e lo restituisce all'app.
Informazioni su questo argomento
Questo argomento offre una descrizione generale e una panoramica della password del proprietario della risorsa OAuth 2.0 concedere il flusso dei tipi di autorizzazione e discutere di 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 fuori. È un esempio end-to-end che illustra il tipo di concessione della password. Garantisce un'esperienza che consiste nell'autenticare le credenziali (chiave/segreto) dell'app client prima di inviare le credenziali dell'utente a un provider di identità.
Video
Video: guarda questo video su come implementare la concessione della password di testo.
Casi d'uso
Questo tipo di autorizzazione è destinato ad app altamente affidabili o con privilegi perché l'utente è obbligatorio per assegnare 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 fungendo da server di autorizzazione.
Suggerimento: per vedere una versione più grande di questo diagramma, fai clic con il tasto destro del mouse sul diagramma e aprilo in nuova scheda o salvarla e aprirla in un visualizzatore di immagini.
Passaggi nel flusso del tipo di autorizzazione 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 recuperare l'ID e le chiavi client secret. Consulta Registrazione di app client per i dettagli.
1. 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 una nell'app), l'utente viene reindirizzato a un modulo di accesso.
2. Richieste di app un token di accesso di Apigee
L'app invia una richiesta di token di accesso, con 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 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 per curl per creare automaticamente l'intestazione 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 dovrebbe essere su un'unica riga).
Le credenziali utente sono contenute nei parametri del modulo, mentre le credenziali client sono è codificato nell'intestazione dell'autenticazione di base HTTP. Per una descrizione dettagliata di questa chiamata API, inclusi i dettagli sull'intestazione Autorizzazione di base richiesta, consulta la sezione per la concessione della password di "Scarica i token OAuth 2.0".
3. Apigee convalida il client app
Prima di inviare il nome utente e la password dell'utente a un provider di identità, Edge deve conoscere che l'app client che effettua la richiesta sia un'app valida e attendibile. Un modo per farlo è utilizzare l'API con l'autenticazione della chiave nella chiamata API. In alcuni casi, potresti voler convalidare sia la chiave client e secret. Esiste un esempio di proxy che illustra questa tecnica allterna nel api-platform-samples su GitHub.
4. Apigee elabora credenziali di accesso
Una volta convalidata l'app client, puoi utilizzare un criterio di callout di servizio o JavaScript per chiamare il servizio di identità, inviando le credenziali dell'utente. Ad esempio, un servizio LDAP o qualsiasi servizio che vuoi utilizzare per convalidare le credenziali. Per maggiori dettagli su queste norme, consulta Estrarre variabili policy e JavaScript .
Se il servizio di identità convalida le credenziali e restituisce una risposta 200, Apigee continuare a elaborare la richiesta; altrimenti Apigee interrompe l'elaborazione e restituisce un errore dell'app client.
5. Il criterio OAuthV2 esegue
Se le credenziali sono valide, il passaggio di elaborazione successivo prevede l'esecuzione di un criterio OAuthV2. per il tipo di autorizzazione della password. Ecco un esempio. L'elemento <UserName> e <PassWord> sono obbligatori ed è possibile recuperarli dalle variabili di flusso sono state salvate con il criterio ExtractVariables. Per informazioni di riferimento dettagliate su queste norme, 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, viene generata una risposta al client contenente un accesso di accesso. La risposta è in formato JSON. Ecco un esempio. Tieni presente che access_token è uno dei 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 cliente chiama API Protected
Ora, con un codice di accesso valido, il client può effettuare chiamate all'API protetta. In questo le richieste vengono inviate ad Apigee (il proxy), che è responsabile della convalida il token di accesso prima di passare la chiamata API al server di risorse di destinazione. Token di accesso vengono passate in un'intestazione Autorizzazione. Ad esempio:
$ curl -H "Authorization: Bearer I6daIgMSiUgYX1K2qgQWPi37ztS6
" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282