Ottenere i token OAuth 2.0

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Questo documento mostra come ottenere token di accesso e codici di autorizzazione OAuth 2.0 con l'API Apigee. Vediamo inoltre come creare criteri per ogni tipo di autorizzazione OAuth 2.0 e configurare gli endpoint proxy in modo che accettino le richieste dei client.

Utilizza il tipo di concessione del codice di autorizzazione

Questa sezione spiega come ottenere un token di accesso utilizzando il flusso del tipo di concessione del codice di autorizzazione. La richiesta di token per questo flusso richiede un codice di autorizzazione. Vedi Ottenere un codice di autorizzazione. Consulta anche la sezione Che cosa sono i tipi di autorizzazione OAuth 2.0.

Richiesta di esempio

curl -i -H 'Content-Type: application/x-www-form-urlencoded' \
   -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \
   -X POST 'https://apitest.acme.com/oauth/token' \
   -d 'code=I9dMGHAN&grant_type=authorization_code&redirect_uri=http://example-callback.com'

Parametri obbligatori

Per impostazione predefinita, questi parametri devono essere x-www-form-urlencoded e specificati nel corpo della richiesta (come mostrato nell'esempio precedente). Tuttavia, è possibile modificare questo valore predefinito configurando gli elementi <GrantType>, <Code> e <RedirectUri> nel criterio OAuthV2. Consulta le norme OAuthV2.

  • grant_type: deve essere impostato sul valore authorization_code.
  • code - Il codice di autorizzazione. Consulta la sezione Richiesta di un codice di autorizzazione.
  • redirect_uri: devi fornire questo parametro se il parametro redirect_uri è stato incluso nella richiesta del codice di autorizzazione. Se il parametro redirect_uri non è stato incluso nella richiesta del codice di autorizzazione e non lo specifichi, questo criterio utilizza il valore dell'URL di callback fornito nell'app sviluppatore registrata.

Parametri facoltativi

  • state - Una stringa che verrà inviata con la risposta. Utilizzato in genere per prevenire attacchi di falsificazione di richieste tra siti.
  • scope: consente di filtrare l'elenco dei prodotti API con cui è possibile utilizzare il token coniato. Per informazioni dettagliate sull'ambito, consulta l'articolo sull'utilizzo degli ambiti OAuth2.

Autorizzazione

Devi passare l'ID client e il client secret come intestazione di autorizzazione di base (con codifica Base64) o come parametri di modulo client_id e client_secret. Questi valori vengono ricavati da un'app sviluppatore registrata. Vedi anche Codifica delle credenziali di autenticazione di base.

Endpoint di esempio

Di seguito è riportata una configurazione di endpoint di esempio per la generazione di un token di accesso. Verrà eseguito il criterio GeneraAccessToken, che deve essere configurato per supportare il tipo di autorizzazione allow_code.

...
       <Flow name="generate-access-token">
            <Description>Generate a token</Description>
            <Request>
                <Step>
                    <Name>GenerateAccessToken</Name>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/token") and (request.verb = "POST")</Condition>
        </Flow>
...

Criterio di esempio

Questo è un criterio GeneraAccessToken di base configurato per accettare il tipo di autorizzazione authorization_code. Per informazioni sugli elementi facoltativi di configurazione che puoi configurare con questo criterio, consulta il criterio OAuthV2.

<OAuthV2 name="GenerateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>1800000</ExpiresIn>
    <RefreshTokenExpiresIn>86400000</RefreshTokenExpiresIn>
    <SupportedGrantTypes>
      <GrantType>authorization_code</GrantType>
    </SupportedGrantTypes>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Restituisce

Se <GenerateResponse> è abilitato, il criterio restituisce una risposta JSON che include il token di accesso, come mostrato di seguito. Il tipo di autorizzazione authorization_code crea un token di accesso e un token di aggiornamento, pertanto una risposta potrebbe essere la seguente:

{
    "issued_at": "1420262924658",
    "scope": "READ",
    "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
    "refresh_token_issued_at": "1420262924658",
    "status": "approved",
    "refresh_token_status": "approved",
    "api_product_list": "[PremiumWeatherAPI]",
    "expires_in": "1799", //--in seconds
    "developer.email": "tesla@weathersample.com",
    "organization_id": "0",
    "token_type": "BearerToken",
    "refresh_token": "fYACGW7OCPtCNDEnRSnqFlEgogboFPMm",
    "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
    "access_token": "2l4IQtZXbn5WBJdL6EF7uenOWRsi",
    "organization_name": "docs",
    "refresh_token_expires_in": "86399", //--in seconds
    "refresh_count": "0"
}

Se <GenerateResponse> viene impostato su false, il criterio non restituisce una risposta. Al contrario, compila il seguente insieme di variabili di flusso con i dati relativi alla concessione del token di accesso.

oauthv2accesstoken.{policy-name}.access_token
oauthv2accesstoken.{policy-name}.expires_in //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token
oauthv2accesstoken.{policy-name}.refresh_token_expires_in //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token_issued_at
oauthv2accesstoken.{policy-name}.refresh_token_status

Ad esempio:

oauthv2accesstoken.GenerateAccessToken.access_token
oauthv2accesstoken.GenerateAccessToken.expires_in
oauthv2accesstoken.GenerateAccessToken.refresh_token
oauthv2accesstoken.GenerateAccessToken.refresh_token_expires_in
oauthv2accesstoken.GenerateAccessToken.refresh_token_issued_at
oauthv2accesstoken.GenerateAccessToken.refresh_token_status

Utilizza il tipo di concessione delle credenziali client

Questa sezione spiega come ottenere un token di accesso utilizzando il flusso di tipo di autorizzazione delle credenziali client. Consulta anche la sezione Che cosa sono i tipi di autorizzazione OAuth 2.0.

Richiesta di esempio

curl -H "Content-Type: application/x-www-form-urlencoded" \
  -H "Authorization: Basic c3FIOG9vSGV4VHo4QzAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ" \
  -X POST "https://apitest.acme.com/oauth/token" \
  -d "grant_type=client_credentials"

Parametri obbligatori

  • grant_type: deve essere impostato sul valore client_credentials.

    Per impostazione predefinita, il parametro grant_type obbligatorio deve essere x-www-form-urlencoded e deve essere specificato nel corpo della richiesta (come mostrato nell'esempio precedente). Tuttavia, è possibile modificare questo valore predefinito configurando l'elemento <GrantType> nel criterio OAuthV2. Ad esempio, potresti scegliere di passare il parametro in un parametro di query. Per maggiori dettagli, consulta il criterio OAuthV2.

Parametri facoltativi

  • state - Una stringa che verrà inviata con la risposta. Utilizzato in genere per prevenire attacchi di falsificazione di richieste tra siti.
  • scope: consente di filtrare l'elenco dei prodotti API con cui è possibile utilizzare il token coniato. Per informazioni dettagliate sull'ambito, consulta l'articolo sull'utilizzo degli ambiti OAuth2.

Autorizzazione

Devi passare l'ID client e il client secret come intestazione di autorizzazione di base (con codifica Base64) o come parametri di modulo client_id e client_secret. Puoi ottenere questi valori dall'app dello sviluppatore registrata associata alla richiesta. Vedi anche Codifica delle credenziali di autenticazione di base.

Endpoint di esempio

Di seguito è riportata una configurazione di endpoint di esempio per la generazione di un token di accesso. Verrà eseguito il criterio GeneraAccessToken, che deve essere configurato per supportare il tipo di autorizzazione client_credentials.

...
       <Flow name="generate-access-token">
            <Request>
                <Step>
                    <Name>GenerateAccessToken</Name>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/token") and (request.verb = "POST")</Condition>
        </Flow>
...

Criterio di esempio

Questo è un criterio GeneraAccessToken di base configurato per accettare il tipo di autorizzazione client_credentials. Per informazioni sugli elementi facoltativi di configurazione che puoi configurare con questo criterio, consulta il criterio OAuthV2.

<OAuthV2 name="GenerateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
    <SupportedGrantTypes>
      <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Restituisce

Se il criterio <GenerateResponse> è abilitato, il criterio restituisce una risposta JSON. Tieni presente che con il tipo di autorizzazione client_credentials, i token di aggiornamento non sono supportati. Viene creato un solo token di accesso. Ad esempio:

{
    "issued_at": "1420260525643",
    "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
    "scope": "READ",
    "status": "approved",
    "api_product_list": "[PremiumWeatherAPI]",
    "expires_in": "1799", //--in seconds
    "developer.email": "tesla@weathersample.com",
    "organization_id": "0",
    "token_type": "BearerToken",
    "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
    "access_token": "XkhU2DFnMGIVL2hvsRHLM00hRWav",
    "organization_name": "docs"
}

Se <GenerateResponse> viene impostato su false, il criterio non restituisce una risposta. Al contrario, compila il seguente insieme di variabili di flusso con i dati relativi alla concessione del token di accesso.

oauthv2accesstoken.{policy-name}.access_token
oauthv2accesstoken.{policy-name}.expires_in //--in seconds

Ad esempio:

oauthv2accesstoken.GenerateAccessToken.access_token
oauthv2accesstoken.GenerateAccessToken.expires_in     //--in seconds

Utilizzare il tipo di autorizzazione della password

Questa sezione spiega come ottenere un token di accesso utilizzando il flusso di tipo di autorizzazione delle credenziali della password del proprietario della risorsa (password). Vedi anche Implementazione del tipo di concessione delle password. Consulta anche la sezione Che cosa sono i tipi di autorizzazione OAuth 2.0.

Richiesta di esempio

curl -v -k -H "Content-Type: application/x-www-form-urlencoded" \
  -H "Authorization: Basic c3FIOG9vSGV4VHo4QzAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ" \
  -X POST "https://apitest.acme.com/oauth/token" \
  -d "grant_type=password&username=a_username&password=a_password"

Parametri obbligatori

Per impostazione predefinita, questi parametri devono essere x-www-form-urlencoded e specificati nel corpo della richiesta (come mostrato nell'esempio precedente). Tuttavia, è possibile modificare questo valore predefinito configurando gli elementi <GrantType>, <Username> e <Password> nel criterio OAuthV2. Consulta le norme OAuthV2.

Le credenziali utente vengono in genere convalidate in base a un archivio credenziali utilizzando un criterio LDAP o JavaScript.

  • grant_type: deve essere impostato sul valore password.
  • username - Il nome utente del proprietario della risorsa.
  • password: la password del proprietario della risorsa.

Parametri facoltativi

  • state - Una stringa che verrà inviata con la risposta. Utilizzato in genere per prevenire attacchi di falsificazione di richieste tra siti.
  • scope: consente di filtrare l'elenco dei prodotti API con cui è possibile utilizzare il token coniato. Per informazioni dettagliate sull'ambito, consulta l'articolo sull'utilizzo degli ambiti OAuth2.

Autorizzazione

Devi passare l'ID client e il client secret come intestazione di autorizzazione di base (con codifica Base64) o come parametri di modulo client_id e client_secret. Puoi ottenere questi valori dall'app dello sviluppatore registrata associata alla richiesta. Vedi anche Codifica delle credenziali di autenticazione di base.

Endpoint di esempio

Di seguito è riportata una configurazione di endpoint di esempio per la generazione di un token di accesso. Verrà eseguito il criterio GeneraAccessToken, che deve essere configurato per supportare il tipo di autorizzazione della password.

...
       <Flow name="generate-access-token">
            <Request>
                <Step>
                    <Name>GenerateAccessToken</Name>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/token") and (request.verb = "POST")</Condition>
        </Flow>
...

Criterio di esempio

Questo è un criterio GeneraAccessToken di base configurato per accettare il tipo di autorizzazione della password. Per informazioni sugli elementi di configurazione facoltativi che puoi configurare con questo criterio, consulta il criterio OAuthV2.

<OAuthV2 name="GenerateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
    <RefreshTokenExpiresIn>28800000</RefreshTokenExpiresIn> <!-- 8 hours -->
    <SupportedGrantTypes>
      <GrantType>password</GrantType>
    </SupportedGrantTypes>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Restituisce

Se il criterio <GenerateResponse> è abilitato, il criterio restituisce una risposta JSON. Tieni presente che, con il tipo di autorizzazione della password, vengono creati sia un token di accesso sia un token di aggiornamento. Ad esempio:

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

Se <GenerateResponse> viene impostato su false, il criterio non restituisce una risposta. Al contrario, compila il seguente insieme di variabili di flusso con i dati relativi alla concessione del token di accesso.

oauthv2accesstoken.{policy-name}.access_token
oauthv2accesstoken.{policy-name}.expires_in   //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token
oauthv2accesstoken.{policy-name}.refresh_token_expires_in  //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token_issued_at
oauthv2accesstoken.{policy-name}.refresh_token_status

Ad esempio:

oauthv2accesstoken.GenerateAccessToken.access_token
oauthv2accesstoken.GenerateAccessToken.expires_in
oauthv2accesstoken.GenerateAccessToken.refresh_token
oauthv2accesstoken.GenerateAccessToken.refresh_token_expires_in
oauthv2accesstoken.GenerateAccessToken.refresh_token_issued_at
oauthv2accesstoken.GenerateAccessToken.refresh_token_status

Utilizza il tipo di autorizzazione implicita

Questa sezione spiega come ottenere un token di accesso utilizzando il flusso del tipo di autorizzazione implicita. Consulta anche la sezione Che cosa sono i tipi di autorizzazione OAuth 2.0.

Richiesta di esempio

$ curl -X POST -H 'Content-Type: application/x-www-form-urlencoded' \
  'https://apitest.acme.com/oauth/implicit?response_type=token&client_id=c3FIOG9vSGV4VHo4QzAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ&redirect_uri=http://callback-example.com'

Parametri obbligatori

Per impostazione predefinita, questi parametri devono essere parametri di ricerca (come mostrato nell'esempio sopra). Tuttavia, è possibile modificare questo valore predefinito configurando gli elementi <ResponseType>, <ClientId> e <RedirectUri> nel criterio OAuthV2 collegato a questo endpoint /token. Per maggiori dettagli, consulta il criterio OAuthV2.

Le credenziali utente vengono in genere convalidate in un archivio credenziali utilizzando un callout del servizio LDAP o un criterio JavaScript.

  • response_type - Deve essere impostato sul valore token.
  • client_id: l'ID client di un'app sviluppatore registrata.
  • redirect_uri: questo parametro è obbligatorio se non è stato fornito un URI di callback al momento della registrazione dell'app sviluppatore client. Se al momento della registrazione del client è stato fornito un URL di callback, questo verrà confrontato con questo valore e deve corrispondere esattamente.

Parametri facoltativi

  • state - Una stringa che verrà inviata con la risposta. Utilizzato in genere per prevenire attacchi di falsificazione di richieste tra siti.
  • scope: consente di filtrare l'elenco dei prodotti API con cui è possibile utilizzare il token coniato. Per informazioni dettagliate sull'ambito, consulta l'articolo sull'utilizzo degli ambiti OAuth2.

Autorizzazione

Non richiede l'intestazione Authorization, ma devi passare un ID client come parametro di richiesta.

Endpoint di esempio

Di seguito è riportata una configurazione di endpoint di esempio per la generazione di un token di accesso. Verrà eseguito il criterio GeneraAccessTokenImplicitGrant.

...
       <Flow name="generate-access-token-implicit">
            <Request>
                <Step>
                    <Name>GenerateAccessTokenImplicitGrant</Name>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/implicit") and (request.verb = "POST")</Condition>
        </Flow>
...

Criterio di esempio

Questo è un criterio GeneraAccessTokenImplicitGrant di base che elabora le richieste di token per il flusso del tipo di autorizzazione implicita. Per informazioni sugli elementi facoltativi di configurazione che puoi configurare con questo criterio, consulta il criterio OAuthV2.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 name="GenerateAccessTokenImplicit">
    <DisplayName>GenerateAccessTokenImplicit</DisplayName>
    <Operation>GenerateAccessTokenImplicitGrant</Operation>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Restituisce

Se <GenerateResponse> è abilitato, il criterio restituisce un reindirizzamento di località 302 nell'intestazione della risposta. Il reindirizzamento rimanda all'URL specificato nel parametro redirect_uri e viene aggiunto il token di accesso e la relativa data di scadenza. Tieni presente che il tipo di concessione implicita non supporta i token di aggiornamento. Ad esempio:

https://callback-example.com#expires_in=1799&access_token=In4dKm4ueoGZRbIYJhC9yZCmTFw5

Se <GenerateResponse> viene impostato su false, il criterio non restituisce una risposta. Al contrario, compila il seguente insieme di variabili di flusso con i dati relativi alla concessione del token di accesso.

oauthv2accesstoken.{policy-name}.access_token
oauthv2accesstoken.{policy-name}.expires_in  //--in seconds

Ad esempio:

oauthv2accesstoken.GenerateAccessToken.access_token
oauthv2accesstoken.GenerateAccessToken.expires_in   //--in seconds

Ottenere un codice di autorizzazione

Nel flusso del tipo di concessione del codice di autorizzazione, è necessario un codice di autorizzazione per ottenere un token di accesso. Vedi Utilizzare il tipo di concessione del codice di autorizzazione. Consulta anche la sezione Che cosa sono i tipi di autorizzazione OAuth 2.0.

Richiesta di esempio

curl -X POST -H "Content-Type: application/x-www-form-urlencoded" \
  "https://apitest.acme.com/oauth/authorize?response_type=code&client_id=c3FIOG9vSGV4VHo4QzAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ&redirect_uri=http://my-callback.com"

Parametri obbligatori

Per impostazione predefinita, questi parametri devono essere parametri di ricerca (come mostrato nell'esempio sopra). Tuttavia, è possibile modificare questo valore predefinito configurando gli elementi <ResponseType>, <ClientId> e <RedirectUri> nel criterio OAuthV2. Per maggiori dettagli, consulta il criterio OAuthV2.

  • redirect_uri: se nell'app client registrata viene specificato un URI di callback completo (non parziale), questo parametro è facoltativo, altrimenti obbligatorio. Il callback è l'URL a cui Apigee invia il codice di autorizzazione appena creato. Vedi anche Registrare app e gestire le chiavi API.
  • response_type - Deve essere impostato sul valore code.
  • client_id: l'ID client di un'app sviluppatore registrata.

Parametri facoltativi

  • redirect_uri: se nell'app client registrata viene specificato un URI di callback completo (non parziale), questo parametro è facoltativo, altrimenti obbligatorio. Il callback è l'URL a cui Apigee invia il codice di autorizzazione appena creato. Vedi anche Registrare app e gestire le chiavi API.
  • state - Una stringa che verrà inviata con la risposta. Utilizzato in genere per prevenire attacchi di falsificazione di richieste tra siti.
  • scope: consente di filtrare l'elenco dei prodotti API con cui è possibile utilizzare il token coniato. Per informazioni dettagliate sull'ambito, consulta l'articolo sull'utilizzo degli ambiti OAuth2.

Autorizzazione

Non richiede l'intestazione Authorization, ma l'ID client dell'app client registrata deve essere specificato nella richiesta.

Criterio di esempio

Questo è un criterio di CreateAuthorizationCode di base. Per ulteriori opzioni di configurazione, consulta il criterio OAuthV2:

<OAuthV2 name="GenerateAuthorizationCode">
    <Operation>GenerateAuthorizationCode</Operation>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Restituisce

Se <GenerateResponse> è abilitato, il criterio restituisce il parametro di query ?code alla località redirect_uri (URI di callback) con il codice di autorizzazione associato. Viene inviato tramite un reindirizzamento del browser 302 con l'URL nell'intestazione Location della risposta. Ad esempio: ?code=123456.

Se il criterio <GenerateResponse> viene impostato su false, il criterio non restituisce una risposta. Al contrario, compila il seguente insieme di variabili di flusso con i dati relativi al codice di autorizzazione.

oauthv2authcode.{policy-name}.code
oauthv2authcode.{policy-name}.scope
oauthv2authcode.{policy-name}.redirect_uri
oauthv2authcode.{policy-name}.client_id

Ad esempio:

oauthv2authcode.GenerateAuthorizationCode.code
oauthv2authcode.GenerateAuthorizationCode.scope
oauthv2authcode.GenerateAuthorizationCode.redirect_uri
oauthv2authcode.GenerateAuthorizationCode.client_id

Aggiornare un token di accesso

Un token di aggiornamento è una credenziale che utilizzi per ottenere un token di accesso, in genere dopo che il token di accesso è scaduto o non è più valido. Quando ricevi un token di accesso, viene restituito un token di aggiornamento nella risposta.

Richiesta di esempio

Per informazioni sulla codifica dell'intestazione di autenticazione di base nella chiamata seguente, consulta Codifica delle credenziali di autenticazione di base. 

$ curl -X POST \
  -H "Content-type: application/x-www-form-urlencoded" \
  -H "Authorization: Basic c3FIOG9vSGV4VHo4QzAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ" \
  https://apitest.acme.com/oauth/refresh \
  -d "grant_type=refresh_token&refresh_token=yVSL38WpuN3Kzn1UTMoE6AQ4ANZM"

Parametri obbligatori

Per impostazione predefinita, il criterio cerca questi parametri come parametri x-www-form-urlencoded specificati nel corpo della richiesta, come mostrato nell'esempio precedente. Per configurare una posizione alternativa per questi input, puoi utilizzare gli elementi <GrantType> e <RefreshToken> nel criterio OAuthV2. Per maggiori dettagli, consulta il criterio OAuthV2.

  • grant_type: deve essere impostato sul valore refresh_token.
  • refresh_token: il token di aggiornamento associato al token di accesso che vuoi rinnovare.

Parametri facoltativi

  • state - Una stringa che verrà inviata con la risposta. Utilizzato in genere per prevenire attacchi di falsificazione di richieste tra siti.
  • scope: consente di filtrare l'elenco dei prodotti API con cui è possibile utilizzare il token coniato. Per informazioni dettagliate sull'ambito, consulta l'articolo sull'utilizzo degli ambiti OAuth2.

Autorizzazione

Non richiede l'intestazione Authorization, ma l'ID client dell'app client registrata deve essere specificato nella richiesta.

Quando aggiorni un token di accesso, l'utente non esegue alcuna riautenticazione.

Di seguito è riportata una configurazione di endpoint di esempio per generare un token di accesso utilizzando un token di aggiornamento. Verrà eseguito il criterio UpdateAccessToken.

 ...
       <Flow name="generate-refresh-token">
            <Request>
                <Step>
                    <Name>RefreshAccessToken</Name>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/refresh") and (request.verb = "POST")</Condition>
       </Flow>
...

Criterio di esempio

Questo è un criterio UpdateAccessToken di base configurato per accettare il tipo di autorizzazione refresh_token. Per informazioni sugli elementi facoltativi di configurazione che puoi configurare con questo criterio, consulta il criterio OAuthV2.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 name="RefreshAccessToken">
    <Operation>RefreshAccessToken</Operation>
    <GenerateResponse enabled="true"/>
    <ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
    <RefreshTokenExpiresIn>28800000</RefreshTokenExpiresIn> <!-- 8 hours -->
</OAuthV2>

Restituisce

Se <GenerateResponse> è abilitato, il criterio restituisce una risposta JSON contenente il nuovo token di accesso. Il tipo di autorizzazione refresh_token supporta il minting sia di token di accesso sia di nuovi token di aggiornamento. Ad esempio:

{
    "issued_at": "1420301470489",
    "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
    "scope": "READ",
    "refresh_token_issued_at": "1420301470489",
    "status": "approved",
    "refresh_token_status": "approved",
    "api_product_list": "[PremiumWeatherAPI]",
    "expires_in": "1799", //--in seconds
    "developer.email": "tesla@weathersample.com",
    "token_type": "BearerToken",
    "refresh_token": "8fKDHLryAD9KFBsrpixlq3qPJnG2fdZ5",
    "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
    "access_token": "jmZ2Hqv3iNsABUtAAsfWR3QGNctw",
    "organization_name": "docs",
    "refresh_token_expires_in": "28799", //--in seconds
    "refresh_count": "2"
}

Tieni presente che, dopo il mining di un nuovo token di aggiornamento, l'originale non è più valido.

La risposta riportata sopra è quella che ricevi se <GenerateResponse> è impostato su true. Se il criterio <GenerateResponse> viene impostato su false, il criterio non restituisce una risposta. Piuttosto, compila il seguente insieme di variabili di contesto (flusso) con i dati relativi alla concessione del token di accesso.

oauthv2accesstoken.{policy-name}.access_token
oauthv2accesstoken.{policy-name}.expires_in   //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token
oauthv2accesstoken.{policy-name}.refresh_token_expires_in  //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token_issued_at
oauthv2accesstoken.{policy-name}.refresh_token_status

Ad esempio:

oauthv2accesstoken.RefreshAccessToken.access_token
oauthv2accesstoken.RefreshAccessToken.expires_in
oauthv2accesstoken.RefreshAccessToken.refresh_token
oauthv2accesstoken.RefreshAccessToken.refresh_token_expires_in
oauthv2accesstoken.RefreshAccessToken.refresh_token_issued_at
oauthv2accesstoken.RefreshAccessToken.refresh_token_status

Codifica delle credenziali di autenticazione di base

È buona norma effettuare una chiamata API per richiedere un token o un codice di autorizzazione, ed è consigliato dalla specifica OAuth 2.0 di passare i valori client_id e client_secret come intestazione di autorizzazione HTTP-Base, come descritto in RFC 2617 di IETF. Per farlo, devi codificare in base64 il risultato dell'unione dei due valori, separandoli con due punti.

In pseudocodice:

result = Base64Encode(concat('ns4fQc14Zg4hKFCNaSzArVuwszX95X', ':', 'ZIjFyTsNgQNyxI'))

Dove: ns4fQc14Zg4hKFCNaSzArVuwszX95X è il client_id e ZIjFyTsNgQNyxI è il client secret.

Esempi

Questo comando di esempio funziona su Linux e MacOS:

export CREDENTIALS=$(echo -n 'ns4fQc14Zg4hKFCNaSzArVuwszX95X:ZIjFyTsNgQNyxI' | base64)

Quindi, puoi effettuare la richiesta di token come segue:

$ curl -i -H "Content-Type: application/x-www-form-urlencoded" \
  -H "Authorization: Basic $CREDENTIALS" \
  -X POST "https://apitest.acme.com/oauth/token" \
  -d "grant_type=client_credentials"

Hashing dei token nel database

Apigee esegue l'hashing di tutti i token di accesso e aggiornamento OAuth per proteggerli in caso di violazione della sicurezza del database. Tu utilizzi token non sottoposti ad hashing nelle chiamate API e Apigee li convalida in base alle versioni con hash nel database.

Argomenti correlati