Questa pagina è stata tradotta dall'API Cloud Translation.

Utilizzo di token OAuth di terze parti

Questa pagina si applica a Apigee e Apigee ibridi.

Visualizza documentazione di Apigee Edge.

In questo argomento, illustreremo come importare token di accesso, token di aggiornamento o codici di autenticazione generati esternamente nel token store di Apigee. Puoi usare questa tecnica se desideri configurare Apigee per convalidare i token generati al di fuori di Apigee.

Come di consueto, Apigee genererà e archivierà un token OAuth e lo restituirà al applicazione di chiamata. L'app chiamante restituisce quindi il token ad Apigee al momento della richiesta e Apigee, tramite il criterio OAuthV2 con Operazione = VerifyAccessToken, per verificare che il token sia valido. Questo argomento descrive come configurare Apigee per memorizzare un token OAuth generato altrove, mantenendo invariata la parte di verifica del token, come se il token fosse stato generato da Apigee.

Esempio

Se vuoi vedere un esempio funzionante che illustra la tecnica descritti in questo argomento, dai un'occhiata al Centro risorse Apigee Esempio di gestione del token delega.

Che cos'è?

Supponiamo che tu abbia un sistema di autorizzazione esistente e che tu voglia utilizzare i valori del codice o del token generati da tale sistema al posto dei valori del codice o del token OAuth2 che le risorse generate da Apigee. Puoi quindi effettuare richieste di proxy API sicure con il token o il codice sostitutivo e Apigee le convaliderà come se fossero state generate da Apigee.

Alcune informazioni di base

Nel solito caso, Apigee genera un token producendo una stringa casuale di lettere e numeri. Apigee associa a questo token altri dati, come la data di emissione, la scadenza, l'elenco dei prodotti API per i quali il token è valido e l'ambito. Tutto questo possono essere restituite in una risposta generata automaticamente dal criterio OAuthV2. configurato con l'operazione = GenerateAccessToken. La risposta ha questo aspetto:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "zBC90HhCGmGlaMBWeZAai2s3za5j",
  "organization_name": "myorg",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

Il valore access_token viene utilizzato da Apigee per recuperare i metadati del token. Ad esempio, supponiamo che una richiesta proxy API includa il token di connessione zBC90HhCGmGlaMBWeZAai2s3za5j. Utilizzando il valore del token, Apigee recupera i metadati del token per determinare se il token è valido o meno.

Seguendo i passaggi descritti qui, puoi configurare Apigee per memorizzare un token il cui valore access_token è stato generato da un servizio esterno. Ad esempio, supponiamo che tu abbia un sistema esterno ad Apigee che genera token nel formato "TOKEN-<16 numeri random>". In questo caso, i metadati completi del token archiviati da Apigee potrebbero essere:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "TOKEN-1092837373654221",
  "organization_name": "myorg",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

In questo caso, un'app potrebbe inviare una richiesta a un proxy API, con il token TOKEN-1092837373654221 di portatore, e Apigee potrà convalidarlo. Puoi applicare un pattern di importazione simile codici di autorizzazione e token di aggiornamento.

Parliamo di Validation Client Credenziali

Un prerequisito per la generazione di un token è la convalida del client richiedente. Per impostazione predefinita, Il criterio OAuthV2/GenerateAccessToken in Apigee verifica implicitamente le credenziali del client. Di solito, in una richiesta di un token OAuthV2, client_id e client_secret vengono passati nel Intestazione autorizzazione, codificata tramite autorizzazione di base HTTP (concatenata da due punti, quindi con codifica Base64). Il criterio OAuthV2/GenerateAccessToken in Apigee decodifica l'intestazione, cerca il client_id e verifica che il client_secret passato sia valido per quel client_id. Questo funziona se le credenziali sono note ad Apigee, in altre parole se in Apigee è archiviata un'app per sviluppatori contenente una credenziale che a sua volta contiene client_id e client_secret.

Se le credenziali del client non devono essere convalidate da Apigee, devi progettare il proxy API prima che generi un token per convalidare esplicitamente il client tramite altri mezzi. Spesso mediante le norme di ServiceCallout che si connette a un endpoint remoto nella tua rete.

In un modo o nell'altro, implicitamente o esplicitamente, devi assicurarti che il proxy API che genera token convalida prima le credenziali del client. Tieni presente che la convalida del client è indipendente dalla generazione del token di accesso. Puoi configurare Apigee per entrambe le operazioni, o di fare l'una o l'altra oppure nessuna delle due.

Se vuoi che il criterio OAuthV2/GenerateAccessToken in Apigee convalidi il client rispetto allo store Apigee, imposta l'elemento <ExternalAuthorization> su false all'interno della configurazione del criterio oppure omettilo del tutto. Se vuoi utilizzare un servizio di autorizzazione esterna per convalidare esplicitamente le credenziali client, impostare Da <ExternalAuthorization> a true.

Anche se Apigee potrebbe non convalidare le credenziali del client, è comunque necessaria per client_id in modo che sia noto e gestito da Apigee. Ogni access_token in Apigee, che sia generato da Apigee o da un sistema esterno e poi importato in Apigee, deve essere associato a un'applicazione client, indicata da client_id. Quindi, anche nel caso in cui il criterio OAuthV2/GenerateAccessToken in Apigee non verificherà che client_id e client_secret corrispondono, il criterio verificherà che client_id sia valido, presente e non revocata. Pertanto, come passaggio di configurazione preliminare, potrebbe essere necessario importare client_id tramite l'API amministrativa di Apigee.

Flusso di criteri per OAuth di terze parti su Apigee

Per utilizzare i token di sistemi OAuth di terze parti in Apigee, il flusso per la generazione dell'accesso devono seguire uno dei seguenti pattern.

Convalida external delle credenziali client

ServiceCallout per verificare le credenziali del client in entrata e acquisire un token esterno.
ExtractVariables o un passaggio JavaScript per estrarre il token generato esternamente dalla risposta.
AssignMessage a imposta la variabile ben nota speciale oauth_external_authorization_status. Il valore deve essere true per indicare che le credenziali del client sono valide.
OAuthV2/GenerateAccessToken con l'elemento <ExternalAuthorization> impostato su true e almeno uno tra <ExternalAccessToken>, <ExternalRefreshToken> o <ExternalAuthorizationCode>.

Convalida interna delle credenziali del client

ServiceCallout per acquisire un token esterno.
ExtractVariables o un Passaggio JavaScript per per estrarre il token generato esternamente dalla risposta.
OAuthV2/GenerateAccessToken con l'elemento <ExternalAuthorization> impostato su false e almeno uno tra <ExternalAccessToken>, <ExternalRefreshToken> o <ExternalAuthorizationCode>.

Note sulla configurazione di flusso e criteri

Se vuoi utilizzare un sistema esterno per convalidare le credenziali del client, è compito tuo sviluppare un flusso di criteri che faccia ciò che è necessario. Di solito, utilizzi un criterio ServiceCallout per inviare le credenziali riconosciute esternamente al servizio di autenticazione esterno. In genere, il servizio di autenticazione esterno restituisce una risposta e, se le credenziali sono valide, anche un token di accesso.
Dopo il ServiceCallout, il proxy API deve analizzare la risposta per estrarre lo stato di validità, nonché l'access_token generato esternamente e, eventualmente, il refresh_token.
Nel criterio OAuthV2/GenerateAccessToken, imposta l'elemento <StoreToken> su true e imposta l'elemento <ExternalAuthorization> su true o false, a seconda dei casi.

Quando il criterio OAuthV2/GenerateAccessToken viene eseguito, legge la variabile oauth_external_authorization_status. Se la variabile è impostata e il valore è true, Apigee non tenta di convalidare le credenziali del client. Se la variabile non è impostata o il valore non è true, Apigee tenterà di convalidare le credenziali del client.
Esistono tre elementi per il criterio OAuthV2 che consentono di specificare i dati esterni da importare: <ExternalAccessToken>, <ExternalRefreshToken> e <ExternalAuthorizationCode>. Ognuno di questi elementi accetta una variabile di flusso. Il criterio Apigee leggerà la variabile per trovare token di accesso generato esternamente, token di aggiornamento o codice di autorizzazione. Sta a te implementare criteri e logica per inserire i token o i codici esterni nelle variabili appropriate.

Ad esempio, la seguente configurazione nel criterio OAuthV2 indica ad Apigee di cercare il token in una variabile di contesto denominata external_token.
```
<ExternalAccessToken>external_token</ExternalAccessToken>
```
Devi anche avere un passaggio precedente che imposti la variabile.
Per quanto riguarda l'impostazione della variabile oauth_external_authorization_status, una tecnica comune per impostarla è utilizzare un criterio Assegna messaggio con l'elemento Assegna variabile, come segue:
```
<AssignMessage name="AssignMessage-SetVariable">
    <DisplayName>Assign Message - Set Variable</DisplayName>
    <AssignVariable>
        <Name>oauth_external_authorization_status</Name>
        <Value>true</Value>
    </AssignVariable>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>
```
Ricorda che questo criterio deve trovarsi prima del criterio OAuthV2 con Operation = GenerateAccessToken.

Esempio di criterio OAuthV2

Il seguente criterio OAuthV2 genera un token di accesso dato che Apigee trova un nella variabile di flusso external_access_token.

<OAuthV2 name="OAuth-v20-Store-External-Token">
    <DisplayName>OAuth v2.0 1</DisplayName>
    <Attributes/>
    <ExternalAccessToken>external_access_token</ExternalAccessToken>
    <ExternalAuthorization>true</ExternalAuthorization>
    <Operation>GenerateAccessToken</Operation>
    <GenerateResponse enabled="true">
        <Format>FORM_PARAM</Format>
    </GenerateResponse>
    <ReuseRefreshToken>false</ReuseRefreshToken>
    <StoreToken>true</StoreToken>
    <SupportedGrantTypes>
        <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <ExpiresIn ref='flow.variable'>2400000</ExpiresIn>
</OAuthV2>

Di solito, con il client credenziali, devi fornire un'intestazione per l'autenticazione di base con il client codificato e client secret. Tuttavia, in questo caso non è necessario fornire questa intestazione. Il criterio si aspetta comunque che client_id sia presente nella richiesta e lo convaliderà. Apigee prevede che il documento client_id venga inviato come parte dei dati del modulo di richiesta, ad esempio in request.formparam.client_id.

In teoria, puoi applicare questo pattern a qualsiasi servizio di autorizzazione OAuth2 di terze parti.