Questa pagina è stata tradotta dall'API Cloud Translation.

Utilizzo di token OAuth di terze parti

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

In questo argomento illustreremo come importare i token di accesso, i token di aggiornamento o codici di autorizzazione nell'archivio token Edge. Puoi usare questa tecnica se desideri configurare Apigee Edge per convalidare i token generati al di fuori di Apigee Edge.

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

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 il metodo i valori del codice o del token generati da tale sistema al posto dei valori del codice o del token OAuth2 che viene generato da Edge. Puoi quindi effettuare richieste proxy API sicure con il token o il codice sostituito, ed Edge li convaliderà come se fossero generati da Edge.

Alcune informazioni di base

Nel solito caso, Apigee Edge genera un token producendo una stringa casuale di lettere e numeri. Apigee Edge associa a quel token, altri dati come l'ora di emissione del token, 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": "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 della risposta. Un'app potrebbe inviare una richiesta a un proxy API ospitato in Edge, portante del token di connessione zBC90HhCGmGlaMBWeZAai2s3za5j ed Edge, con il token OAuthV2 con Operation = VerifyAccessToken - cercherà il token, recupererà tutte le informazioni, e utilizzare queste informazioni per determinare se il token è valido o meno per il proxy API richiesto. Questa procedura è chiamata convalida dei token. Tutte le informazioni precedenti costituiscono il token. La Il valore access_token è solo il modo per cercare quelle informazioni.

D'altra parte, seguendo i passaggi descritti qui, puoi configurare Edge per archiviare un in modo che il suo valore access_token sia un elemento generato da un completamente gestito di Google Cloud. Tutti gli altri metadati potrebbero essere uguali. Ad esempio, supponiamo che tu abbia un sistema esterno ad Apigee Edge che genera token nel formato "TOKEN-<16 numeri>" di Google. 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, portando il dispositivo di connessione il token TOKEN-1092837373654221 ed Edge, tramite il criterio OAuthV2 con Operazione = VerificationAccessToken - 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 Edge verifica implicitamente le credenziali del client. Normalmente in una richiesta per un token OAuthV2, client_id e client_secret vengono passati nella Intestazione autorizzazione, codificata tramite autorizzazione di base HTTP (concatenata da due punti, quindi con codifica Base64). Il criterio OAuthV2/GenerateAccessToken in Apigee Edge decodifica tale intestazione e cerca il client_id e verifica che il client_secret passato sia valido client_id. Funziona se le credenziali sono note ad Apigee Edge, ovvero se esiste una App sviluppatore archiviata in Apigee Edge, che contiene una credenziale che a sua volta contiene dato client_id e client_secret.

Nel caso in cui le credenziali client non vengano convalidate da Apigee Edge, devi progettare il proxy API, prima che generi un token, per convalidare esplicitamente il client tramite in altri modi. 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 indipendente dalla generazione del token di accesso. Puoi configurare Apigee Edge 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 Edge convalidi il client credenziali sull'archivio perimetrale, 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 Edge potrebbe non convalidare le credenziali del client, è comunque necessario per che sia noto e gestito da Apigee Edge. Ogni access_token in Apigee Edge, sia generati da Apigee Edge o da un sistema esterno, quindi importati in Apigee Edge, Deve essere associato a un'applicazione client, indicato dal client_id. Quindi, anche nel caso dove il criterio OAuthV2/GenerateAccessToken in Apigee Edge non convaliderà il valore client_id e client_secret corrispondono, il criterio convaliderà che il client_id sia valido, presente e non revocata. Quindi, come passaggio di configurazione prerequisito, potresti dover importare client_id tramite Edge l'API amministrativa.

Flusso di criteri per OAuth di terze parti su Apigee

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

Esterni Convalida delle credenziali client

ServiceCallout per verificare le credenziali del client in entrata e acquisire un token esterno.
ExtractVariables o un Passaggio JavaScript per 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 il token Elemento <ExternalAuthorization> impostato su true e almeno uno di <ExternalAccessToken>, <ExternalRefreshToken> o <ExternalAuthorizationCode>.

Interno Convalida delle credenziali client

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

Note sulla configurazione di flusso e criteri

Se vuoi utilizzare un sistema esterno per convalidare le credenziali del client, per sviluppare un flusso di norme che faccia ciò che è necessario. Normalmente useresti criterio ServiceCallout per inviare le credenziali riconosciute esternamente all'esterno di autenticazione sicura. Il servizio di autenticazione esterna in genere restituisce una risposta e, se le credenziali sono valide, anche un token di accesso.
Dopo il callout Service, il proxy API deve analizzare la risposta per estrarre il valore nonché il token access_token generato esternamente ed eventualmente 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 Edge non tenta di convalidare le credenziali client. Se la variabile non è impostato o il valore non è true, Apigee Edge tenterà di convalidare il client e credenziali.
Esistono tre elementi per il criterio OAuthV2 che consentono di specificare l'indirizzo dati da importare: <ExternalAccessToken>, <ExternalRefreshToken>, e <ExternalAuthorizationCode>. Ciascuno di questi elementi accetta variabile di flusso. Il criterio Edge leggerà la variabile per trovare il token di accesso, token di aggiornamento o codice di autorizzazione generati esternamente. Sta a te decidere implementare criteri e logiche per posizionare i token o i codici esterni nel come la codifica one-hot delle variabili categoriche.

Ad esempio, la seguente configurazione nel criterio OAuthV2 indica a Edge di cercare il token in una variabile di contesto denominata external_token.
```
<ExternalAccessToken>external_token</ExternalAccessToken>
```
Devi inoltre specificare un passaggio precedente che imposti la variabile.
Per quanto riguarda l'impostazione della variabile oauth_external_authorization_status, una procedura per impostare questa variabile è utilizzare un criterioAssignMessage con l'elemento AssegnaVariabile in questo modo:
```
<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 precedere il criterio OAuthV2 con Operazione = GenerateAccessToken.

Esempio di criterio OAuthV2

I seguenti criteri OAuthV2 genera un token di accesso Apigee Edge poiché Edge trova 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>

Di solito, con il cliente credenziali, devi fornire un'intestazione per l'autenticazione di base con il client codificato e client secret. In questo caso, però, non è necessario fornire questo intestazione. Il criterio prevede comunque che nella richiesta sia presente client_id e il valore la convalida. Edge prevede che l'elemento 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 con qualsiasi autorizzazione OAuth2 di terze parti completamente gestito di Google Cloud.