Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Utilizzo di token OAuth di terze parti

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

In questo argomento, ti mostreremo come importare token di accesso, token di aggiornamento, o codici di autorizzazione generati esternamente nell'archivio token Edge. Puoi utilizzare questa tecnica se vuoi configurare Apigee Edge per convalidare i token generati al di fuori di Apigee Edge.

In genere, Apigee Edge genera e archivia un token OAuth e lo restituisce all' applicazione chiamante. L'app di chiamate presenta quindi il token ad Apigee Edge quando richiede il servizio e Apigee Edge, tramite la policy OAuthV2 con Operation = VerifyAccessToken, verifica che il token sia valido. Questo argomento descrive come configurare Apigee Edge per archiviare un token OAuth generato altrove, mantenendo invariata la parte di verifica del token, come se il token fosse stato generato da Edge.

Esempio

Se vuoi vedere un esempio pratico che illustra la tecnica descritta in questo argomento, dai un'occhiata all'esempio di gestione dei token delegata di Apigee.

Che cos'è?

Supponiamo che tu abbia un sistema di autorizzazione esistente e che tu voglia utilizzare i valori dei token o dei codici generati da questo sistema al posto dei valori dei token o dei codici OAuth2 che Edge genera. Puoi quindi effettuare richieste proxy API sicure con il token o il codice sostituito, e Edge le convaliderà come se fossero state generate da Edge.

Alcune informazioni di base

In genere, Apigee Edge genera un token producendo una stringa casuale di lettere e numeri. Apigee Edge associa a questo token altri dati, come l'ora di emissione del token, la scadenza, l'elenco dei prodotti API per cui il token è valido e l'ambito. Tutte queste informazioni possono essere restituite in una risposta generata automaticamente dalla policy OAuthV2 configurata con Operation = GenerateAccessToken. La risposta è simile alla seguente:

{
  "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": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

Il valore dell'attributo access_token è effettivamente la chiave di ricerca per i dati di risposta. Un'app potrebbe effettuare una richiesta a un proxy API ospitato in Edge, con il token di autenticazione zBC90HhCGmGlaMBWeZAai2s3za5j, e Edge, con la policy OAuthV2 con Operation = VerifyAccessToken, cercherà il token, recupererà tutte le informazioni e le utilizzerà per determinare se il token è valido o meno per il proxy API richiesto. Questa operazione è chiamata convalida del token. Tutte le informazioni sopra riportate costituiscono il token. Il valore access_token è solo il modo per cercare queste informazioni.

D'altra parte, seguendo i passaggi descritti qui, puoi configurare Edge per archiviare un token in modo che il suo access_token valore sia qualcosa generato da un servizio esterno. Tutti gli altri metadati potrebbero essere gli stessi. Ad esempio, supponiamo che tu abbia un sistema esterno ad Apigee Edge che genera token nel formato "TOKEN-<16 numeri casuali>" . In questo caso, i metadati completi del token archiviati da Apigee Edge 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": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

In questo caso, un'app potrebbe effettuare una richiesta a un proxy API ospitato in Edge, con il token di autenticazione TOKEN-1092837373654221, e Edge, tramite la policy OAuthV2 con Operation = VerifyAccessToken, sarà in grado di convalidarlo. Puoi applicare un pattern di importazione simile a codici di autorizzazione e token di aggiornamento.

Parliamo della convalida delle credenziali client

Un prerequisito per la generazione di un token è la convalida del client richiedente. Per impostazione predefinita, la policy OAuthV2/GenerateAccessToken in Apigee Edge verifica implicitamente le credenziali client. In genere, in una richiesta di token OAuthV2, client_id e client_secret vengono passati nell' intestazione Authorization, codificati tramite l'autorizzazione di base HTTP (concatenati con i due punti, quindi codificati in base64). La policy OAuthV2/GenerateAccessToken in Apigee Edge decodifica questa intestazione e cerca client_id e verifica che client_secret passato sia valido per quel client_id. Questa operazione funziona se le credenziali sono note ad Apigee Edge, in altre parole se in Apigee Edge è memorizzata un'app per sviluppatori che contiene una credenziale, che a sua volta contiene client_id e client_secret specificati.

Se le credenziali client non devono essere convalidate da Apigee Edge, devi progettare il proxy API in modo che, prima di generare un token, convalidi esplicitamente il client tramite altri mezzi. Spesso questa operazione viene eseguita tramite una policy ServiceCallout che si connette a un endpoint remoto nella rete.

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

Se vuoi che la policy OAuthV2/GenerateAccessToken in Apigee Edge convalidi le credenziali client rispetto all'archivio Edge, imposta l'elemento <ExternalAuthorization> su false nella configurazione della policy o omettilo completamente. Se vuoi utilizzare un servizio di autorizzazione esterno per convalidare esplicitamente le credenziali client, imposta <ExternalAuthorization> su true.

Sebbene Apigee Edge non convalidi le credenziali client, è comunque necessario che il client_id sia noto e gestito da Apigee Edge. Ogni access_token in Apigee Edge, sia generato da Apigee Edge sia da un sistema esterno e poi importato in Apigee Edge, deve essere associato a un'applicazione client, indicata da client_id. Pertanto, anche nel caso in cui la policy OAuthV2/GenerateAccessToken in Apigee Edge non convalidi la corrispondenza tra client_id e client_secret, la policy convaliderà che client_id sia valido, presente e non revocato. Pertanto, come passaggio di configurazione preliminare, potresti dover importare client_id tramite l'API amministrativa Edge.

Flusso di policy per OAuth di terze parti su Apigee

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

Convalida esterna delle credenziali client

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

Convalida interna delle credenziali client

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

Note sul flusso e sulla configurazione delle policy

Se vuoi utilizzare un sistema esterno per convalidare le credenziali client, è a te sviluppare un flusso di policy che esegua le operazioni necessarie. In genere, utilizzeresti una policy ServiceCallout per inviare le credenziali riconosciute esternamente al servizio di autenticazione esterno. Il servizio di autenticazione esterno in genere restituisce una risposta e, se le credenziali sono valide, anche un token di accesso.
Dopo ServiceCallout, il proxy API deve analizzare la risposta per estrarre lo stato di validità, nonché access_token generato esternamente ed eventualmente il refresh_token.
Nella policy OAuthV2/GenerateAccessToken, imposta l'elemento <StoreToken> su true e l'elemento <ExternalAuthorization> su true o false, a seconda dei casi.

Quando viene eseguita la policy OAuthV2/GenerateAccessToken, viene letta la variabile oauth_external_authorization_status. Se la variabile è impostata e il valore è true, Apigee Edge non tenta di convalidare le credenziali client. Se la variabile non è impostata o il valore non è true, Apigee Edge tenterà di convalidare le credenziali client.
Esistono tre elementi per la policy OAuthV2 che ti consentono di specificare i dati esterni da importare: <ExternalAccessToken>, <ExternalRefreshToken>, e <ExternalAuthorizationCode>. Ognuno di questi elementi accetta una variabile di flusso. La policy Edge leggerà questa variabile per trovare il token di accesso, il token di aggiornamento o il codice di autorizzazione generato esternamente. Devi implementare policy e logica per inserire i token o i codici esterni nelle variabili appropriate.

Ad esempio, la seguente configurazione nella policy OAuthV2 indica a Edge di cercare il token in una variabile di contesto denominata external_token.
```
<ExternalAccessToken>external_token</ExternalAccessToken>
```
Dovrai anche eseguire un passaggio precedente che imposta questa variabile.
Per quanto riguarda l'impostazione della variabile oauth_external_authorization_status, una tecnica comune per impostare questa variabile consiste nell'utilizzare una policy AssignMessage con l'elemento AssignVariable, 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 questa policy deve essere eseguita prima della policy OAuthV2 con Operation = GenerateAccessToken.

Esempio di policy OAuthV2

La seguente policy OAuthV2 genera un token di accesso Apigee Edge, a condizione che Edge trovi un valore del token nella variabile di flusso external_access_token.

<OAuthV2 name="OAuth-v20-Store-External-Token">
    <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>

In genere, con il tipo di concessione delle credenziali client devi fornire un'intestazione di autenticazione di base con l'ID client e il client secret codificati. Tuttavia, in questo caso, non devi fornire questa intestazione. La policy prevede comunque che client_id sia presente nella richiesta e la policy la convaliderà. Edge prevede che client_id venga inviato come parte dei dati del modulo di richiesta, ad esempio in request.formparam.client_id.

In teoria, potresti applicare questo pattern con qualsiasi servizio di autorizzazione OAuth2 di terze parti