Criterio OAuthV2

Questa pagina si applica a Apigee e Apigee ibrido.

Visualizza la documentazione di Apigee Edge.

La funzionalità dei token di accesso JWT è attualmente disponibile per Apigee e per Apigee hybrid versioni 1.7.0 e successive. Consulta l'articolo Utilizzare i token OAuth JWT.

Cosa

OAuthV2 è un criterio sfaccettato per eseguire operazioni relative ai tipi di autorizzazione OAuth 2.0. Questo è il criterio principale utilizzato per configurare gli endpoint OAuth 2.0 su Apigee.

Questo criterio è un criterio estendibile e il suo utilizzo potrebbe avere implicazioni in termini di costi o utilizzo, a seconda della licenza Apigee. Per informazioni sui tipi di criteri e sulle implicazioni per l'utilizzo, consulta la pagina Tipi di criteri.

Suggerimento: per scoprire di più su OAuth su Apigee, consulta la home page di OAuth. Fornisce link a risorse, esempi, video e altro ancora.

Campioni

VerifyAccessToken

VerifyAccessToken

Questa configurazione di criteri OAuthV2 (con l'operazione VerifyAccessToken) verifica che un token di accesso inviato ad Apigee sia valido. Quando viene attivata questa operazione del criterio, Apigee cerca un token di accesso valido nella richiesta. Se il token di accesso è valido, la richiesta può procedere. Se non è valida, l'intera elaborazione si interrompe e la risposta restituisce un errore.

<OAuthV2 name="OAuthV2-Verify-Access-Token">
    <Operation>VerifyAccessToken</Operation>
</OAuthV2>

Nota: sono supportati solo i token di connessione OAuth 2.0. Altri tipi di token, come i token MAC (Message Authentication Code) non sono supportati.

Un'applicazione client deve inviare una richiesta con un token. Ad esempio, con curl potrebbe essere:

$ curl https://API_ENDPOINT/weather/forecastrss?w=12797282 \
  -H "Authorization: Bearer ylSkZIjbdWybfsUQe9BqP0LH5Z"

Dove API_ENDPOINT è il dominio utilizzato per accedere alle API, come configurato nel sistema Apigee.

Per impostazione predefinita, il criterio OAuthV2 estrae il token di accesso dall'intestazione Authorization, rimuovendo il prefisso Bearer. Puoi modificare questo comportamento predefinito con l'elemento di configurazione AccessToken.

GenerateAccessToken

Generazione dei token di accesso

Per esempi che mostrano come richiedere i token di accesso per ciascuno dei tipi di concessioni supportati, consulta Recuperare i token OAuth 2.0. L'argomento include esempi di queste operazioni:

• Codice di autorizzazione
• Credenziali client
• Implicito
• Password

Nota: il criterio OAuthV2 restituisce alcuni elementi di risposta non conformi a RFC. Ad esempio, il criterio restituisce una proprietà del token, "token_type":"BearerToken", in cui la proprietà del token conforme è "token_type":"Bearer". Per maggiori dettagli su questi elementi di risposta non conformi, vedi Comportamento non conforme a RFC.

GenerateAuthorizationCode

Genera codice di autorizzazione

Per esempi che mostrano come richiedere codici di autorizzazione, consulta Richiesta di un codice di autorizzazione.

RefreshAccessToken

Aggiornare un token di accesso

Per esempi che mostrano come richiedere i token di accesso utilizzando un token di aggiornamento, consulta Aggiornare un token di accesso.

Token di accesso JWT

Token di accesso JWT

Per esempi che mostrano come generare, verificare e aggiornare i token di accesso JWT, consulta Utilizzo dei token di accesso JWT.

Token di flusso di risposta

Genera un token di accesso nel flusso di risposta

A volte potresti dover generare un token di accesso nel flusso di risposta. Ad esempio, puoi farlo in risposta a una convalida personalizzata eseguita in un servizio di backend. In questo esempio, il caso d'uso richiede sia un token di accesso sia un token di aggiornamento, escludendo il tipo di concessione implicita. In questo caso, utilizzeremo il tipo di concessione della password per generare il token. Come vedrai, il trucco per far funzionare questa operazione è passare in un'intestazione della richiesta di autorizzazione con un criterio JavaScript.

Innanzitutto, esaminiamo la norma di esempio:

<OAuthV2 enabled="true" continueOnError="false" async="false" name="generateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <AppEndUser>Doe</AppEndUser>
    <UserName>jdoe</UserName>
    <PassWord>jdoe</PassWord>
    <GrantType>grant_type</GrantType>
    <ClientId>a_valid_client_id</ClientId>
    <SupportedGrantTypes>
        <GrantType>password</GrantType>
    </SupportedGrantTypes>
</OAuthV2>

Se inserisci questo criterio nel flusso di risposta, avrà esito negativo con un errore 401 Non autorizzato anche se nel criterio sono specificati i parametri di accesso corretti. Per risolvere il problema, devi impostare un'intestazione della richiesta di autorizzazione.

L'intestazione Authorization deve contenere uno schema di accesso di base con client_id:client_secret con codifica Base64.

Puoi aggiungere questa intestazione con un criterio JavaScript posizionato subito prima del criterio OAuthV2, in questo modo. Le variabili di contesto "local_clientid" e "local_secret" devono essere precedentemente impostate e disponibili nel flusso:

var clientId = context.getVariable("local_clientid");
var clientSecret = context.getVariable("local_secret");
context.setVariable("request.header.Authorization","Basic "+ CryptoJS.enc.Base64.stringify(CryptoJS.enc.Latin1
                                      .parse(clientId + ':' + clientSecret)));

Vedi anche Codifica delle credenziali di autenticazione di base.

Riferimento dell'elemento

Il riferimento al criterio descrive gli elementi e gli attributi del criterio OAuthV2.

Nota: il modo in cui configuri questo criterio e gli elementi che devi specificare dipendono dall'operazione che vuoi che venga eseguita. Ad esempio, se stai implementando il tipo di concessione del codice di autorizzazione, avrai bisogno di quattro criteri OAuthV2 separati per eseguire la generazione del codice di autorizzazione e del codice di accesso, la convalida del codice di accesso e la generazione del token di aggiornamento. Questo riferimento elenca tutti gli elementi che possono essere utilizzati con questo criterio.

Se vuoi visualizzare le configurazioni per casi d'uso specifici dei tipi di autorizzazione, consulta la home page OAuth per un elenco delle implementazioni dei tipi di autorizzazione.

Il criterio di esempio mostrato di seguito è una delle tante configurazioni possibili. Questo esempio mostra un criterio OAuthV2 configurato per l'operazione GeneraAccessToken. Include elementi obbligatori e facoltativi. Per maggiori dettagli, consulta le descrizioni degli elementi in questa sezione.

<OAuthV2 name="GenerateAccessToken">
  <!-- This policy generates an OAuth 2.0 access token using the client_credentials grant type -->
  <Operation>GenerateAccessToken</Operation>
  <!-- This is in millseconds, so expire in an hour -->
  <ExpiresIn>3600000</ExpiresIn>
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GrantType>request.queryparam.grant_type</GrantType>
  <GenerateResponse/>
</OAuthV2>

Attributi <OAuthV2>

<OAuthV2 async="false" continueOnError="false" enabled="true" name="MyOAuthPolicy">

The following table describes attributes that are common to all policy parent elements:

Attribute	Description	Default	Presence
name	The internal name of the policy. The value of the name attribute can contain letters, numbers, spaces, hyphens, underscores, and periods. This value cannot exceed 255 characters. Optionally, use the <DisplayName> element to label the policy in the management UI proxy editor with a different, natural-language name.	N/A	Required
continueOnError	Set to false to return an error when a policy fails. This is expected behavior for most policies. Set to true to have flow execution continue even after a policy fails. See also: Fault rules are triggered ONLY in an error state (about continueOnError) Handling faults within the current flow	false	Optional
enabled	Set to true to enforce the policy. Set to false to turn off the policy. The policy will not be enforced even if it remains attached to a flow.	true	Optional
async	This attribute is deprecated.	false	Deprecated

<DisplayName> element

Use in addition to the name attribute to label the policy in the management UI proxy editor with a different, natural-language name.

<DisplayName>Policy Display Name</DisplayName>

Default	N/A If you omit this element, the value of the policy's name attribute is used.
Presence	Optional
Type	String

Elemento <AccessToken>

<AccessToken>request.header.access_token</AccessToken>

Per impostazione predefinita, quando Operation è VerifyAccessToken, il criterio prevede che il token di accesso venga inviato nell'intestazione Authorization come token di connessione, ovvero con il prefisso "Bearer", seguito da uno spazio vuoto. Puoi modificare il valore predefinito utilizzando questo elemento, specificando il nome di una variabile contenente il token di accesso da verificare. Quando utilizzi questo elemento, per impostazione predefinita il criterio non cerca un prefisso nei contenuti della variabile. Se vuoi specificare che il criterio deve cercare un prefisso, utilizza anche l'elemento AccessTokenPrefix.

Esempi:

• Quando la configurazione dei criteri è:

    <OAuthV2 name="OAuthV2-Verify-Access-Token-in-Header">
        <Operation>VerifyAccessToken</Operation>
        <AccessToken>request.header.access_token</AccessToken>
    </OAuthV2>

  Per passare il token utilizzando curl, potresti usare:

    curl https://API_ENDPOINT/oauth2/validate -H "access_token:Rft3dqrs56Blirls56a"

• Quando la configurazione dei criteri è:

    <OAuthV2 name="OAuthV2-Verify-Access-Token-in-QueryParam">
        <Operation>VerifyAccessToken</Operation>
        <AccessToken>request.queryparam.token</AccessToken>
    </OAuthV2>

  Per passare il token utilizzando curl, potresti usare:

    curl "https://API_ENDPOINT/oauth2/validate?token=Rft3dqrs56Blirls56a"

Dove API_ENDPOINT è il dominio utilizzato per accedere alle API, come configurato nel tuo sistema Apigee.

Predefinita:	N/A
Presenza:	Facoltativo
Tipo:	String
Valori validi:	qualsiasi nome di variabile
Utilizzato con le operazioni:	VerifyAccessToken

Elemento <AccessTokenPrefix>

<AccessTokenPrefix>Prefix</AccessTokenPrefix>

Per impostazione predefinita, quando Operation è VerifyAccessToken, il criterio prevede che il token di accesso venga inviato nell'intestazione Authorization come token di connessione, ovvero con il prefisso "Bearer", seguito da uno spazio vuoto. Se utilizzi l'elemento AccessToken per specificare una posizione diversa per il token di accesso in entrata, puoi utilizzare anche questo elemento, AccessTokenPrefix, per specificare un prefisso diverso non standard.

Ad esempio, se specifichi:

<OAuthV2 name="OAuthV2-Verify-Access-Token-Alternative-Header">
    <Operation>VerifyAccessToken</Operation>
    <AccessToken>request.header.token</AccessToken>
    <AccessTokenPrefix>KEY</AccessTokenPrefix>
</OAuthV2>

Il criterio estrarrà il token di accesso in entrata dall'intestazione della richiesta token in questo modo: se l'intestazione inizia con la parola "KEY" seguita da uno spazio, il criterio rimuove il prefisso e lo spazio e interpreta il valore rimanente come token di accesso. Se il prefisso specificato non è presente nell'intestazione, il criterio genererà un errore.

Se specifichi l'elemento AccessToken e non specifichi l'elemento AccessTokenPrefix, il criterio interpreterà l'intero valore della variabile specificata all'interno dell'elemento AccessToken come token di accesso.

Questo elemento viene applicato soltanto quando viene utilizzato anche l'elemento AccessToken.

Predefinita:	-nessuno-
Presenza:	Facoltativo
Tipo:	String
Valori validi:	qualsiasi stringa
Utilizzato con le operazioni:	VerifyAccessToken

<Algorithm>

<Algorithm>algorithm-here</Algorithm>

Specifica l'algoritmo di crittografia utilizzato per firmare un token di accesso JWT. Gli algoritmi RSA (RS*) utilizzano una coppia di chiavi pubbliche/segreta, mentre gli algoritmi HMAC (HS*) impiegano un secret condiviso. Questo elemento è obbligatorio per le operazioni GenerateJWTAccessToken, VerifyJWTAccessToken e RefreshJWTAccessToken.

Predefinito	N/A
Presenza	Obbligatorio quando si utilizzano le operazioni GenerateJWTAccessToken, VerifyJWTAccessToken e RefreshJWTAccessToken.
Tipo	String
Valori validi	HS256, HS384, HS512, RS256, RS384, RS512

Elemento <AppEndUser>

<AppEndUser>request.queryparam.app_enduser</AppEndUser>

Nei casi in cui l'ID utente finale dell'app deve essere inviato al server di autorizzazione, questo elemento consente di specificare dove Apigee deve cercare l'ID utente finale. Ad esempio, potrebbe essere inviato come parametro di query o in un'intestazione HTTP.

Ad esempio request.queryparam.app_enduser indica che AppEndUser deve essere presente come parametro di query, come, ad esempio, ?app_enduser=[e-mail]. Ad esempio, per richiedere AppEndUser in un'intestazione HTTP, imposta questo valore su request.header.app_enduser.

Se fornisci questa impostazione, puoi includere un ID utente finale dell'app nel token di accesso. Questa funzionalità è utile se vuoi poter recuperare o revocare i token di accesso OAuth 2.0 in base all'ID utente finale. Per maggiori informazioni, consulta Attivare il recupero e la revoca dei token di accesso OAuth 2.0 per ID utente finale, ID app o entrambi.

Predefinita:	N/A
Presenza:	Facoltativo
Tipo:	String
Valori validi:	Qualsiasi variabile di flusso accessibile al criterio in fase di runtime.
Utilizzati con i tipi di autorizzazione:	authorization_code implicito password client_credentials

<Attributi/Attributo>

<Attributes>
    <Attribute name="attr_name1" ref="flow.variable" display="true|false">value1</Attribute>
    <Attribute name="attr_name2" ref="flow.variable" display="true|false">value2</Attribute>
</Attributes>

Utilizza questo elemento per aggiungere attributi personalizzati a un token di accesso o a un codice di autorizzazione. Ad esempio, potresti voler incorporare un ID utente o un identificatore di sessione in un token di accesso che possa essere estratto e verificato in fase di runtime.

Questo elemento consente di specificare un valore in una variabile di flusso o da una stringa letterale. Se specifichi sia una variabile sia una stringa, viene utilizzato il valore specificato nella variabile di flusso. Se la variabile non può essere risolta, la stringa è quella predefinita.

Per ulteriori informazioni sull'utilizzo di questo elemento, consulta Personalizzazione di token e codici di autorizzazione.

Note:

Puoi creare fino a 18 attributi personalizzati.

Se aggiungi attributi personalizzati a un codice di autorizzazione, questi attributi verranno ereditati dal token di accesso generato da quel codice.

Mostrare o nascondere gli attributi personalizzati nella risposta

Tieni presente che se imposti l'elemento CreateResponse di questo criterio su true, nella risposta verrà restituita la rappresentazione JSON completa del token, inclusi eventuali attributi personalizzati impostati. In alcuni casi, potresti voler nascondere alcuni o tutti gli attributi personalizzati nella risposta in modo che non siano visibili alle app client.

Per impostazione predefinita, gli attributi personalizzati vengono visualizzati nella risposta. Se vuoi nasconderli, puoi impostare il parametro display su false. Ad esempio:

<Attributes>
    <Attribute name="employee_id" ref="employee.id" display="false"/>
    <Attribute name="employee_name" ref="employee.name" display="false"/>
</Attributes>

Il valore dell'attributo display non è persistente. Supponiamo di generare un token di accesso con attributi personalizzati che vuoi nascondere nella risposta generata. L'impostazione di display=false consente di raggiungere l'obiettivo. Tuttavia, se in un secondo momento viene generato un nuovo token di accesso utilizzando un token di aggiornamento, gli attributi personalizzati originali del token di accesso verranno visualizzati nella risposta del token di aggiornamento. Questo perché Apigee non ricorda che l'attributo display sia stato originariamente impostato su false nel criterio di generazione del token di accesso, poiché l'attributo personalizzato fa semplicemente parte dei metadati del token di accesso.

Il comportamento sarà lo stesso se aggiungi attributi personalizzati a un codice di autorizzazione. Quando viene generato un token di accesso utilizzando questo codice, questi attributi personalizzati vengono visualizzati nella risposta del token di accesso. Anche in questo caso, potrebbe non essere il comportamento previsto.

In questi casi, per nascondere gli attributi personalizzati, hai a disposizione le seguenti opzioni:

• Reimposta in modo esplicito gli attributi personalizzati nel criterio del token di aggiornamento e imposta la visualizzazione su false. In questo caso, potresti dover recuperare i valori personalizzati originali dal token di accesso originale utilizzando il criterio GetOAuthV2Info.
• Utilizza un criterio JavaScript di post-elaborazione per estrarre manualmente gli attributi personalizzati che non vuoi vedere nella risposta.

Vedi anche Personalizzazione di token e codici di autorizzazione.

Predefinita:	N/A
Presenza:	Facoltativo
Valori validi:	name - Il nome dell'attributo ref: il valore dell'attributo. Può provenire da una variabile di flusso. display - (Facoltativo) Consente di specificare se nella risposta vengono visualizzati o meno attributi personalizzati. Se true, gli attributi personalizzati vengono visualizzati nella risposta (se è abilitato anche GenerateResponse). Se false, gli attributi personalizzati non sono inclusi nella risposta. Il valore predefinito è true. Consulta Visualizzare o nascondere gli attributi personalizzati nella risposta.
Utilizzati con i tipi di autorizzazione:	authorization_code implicito password client_credentials refresh_token Può essere utilizzato anche con l'operazione generateAuthorizationCode.

Elemento <CacheExpiryInSeconds>

<CacheExpiryInSeconds ref="request.queryparam.cache_expiry">Value 1</CacheExpiryInSeconds>

Questo elemento applica il TTL sulla cache, il che consente la personalizzazione del periodo di tempo per la scadenza del token di accesso memorizzato nella cache. L'intervallo supportato è compreso tra 1 e 180 secondi. Puoi fornire una variabile di flusso e una variabile predefinita. Se fornito, il valore della variabile di flusso ha la precedenza sul valore predefinito specificato.

Questo elemento può essere utilizzato solo con l'operazione VerifyAccessToken.

Nota: si verifica un calo delle prestazioni quando l'intervallo di memorizzazione nella cache si riduce.

Predefinita	N/A Se ometti questo elemento, il periodo di scadenza predefinito per il token di accesso memorizzato nella cache è di 180 secondi.
Presenza	Facoltativo
Tipo	Integer
Valori validi	Qualsiasi numero intero positivo diverso da zero. Specifica la scadenza in secondi.

Attributi

Nella tabella seguente vengono descritti gli attributi dell'elemento <CacheExpiryInSeconds>

Attributo	Descrizione	Predefinita	Presenza
riferimento	Un riferimento alla variabile di flusso contenente il valore per la scadenza della cache, espresso in secondi. Se fornito, il valore della variabile di flusso ha la precedenza sul valore predefinito specificato.	N/A	Facoltativo

Elemento <ClientId>

<ClientId>request.formparam.client_id</ClientId>

In alcuni casi, l'app client deve inviare l'ID client al server di autorizzazione. Questo elemento consente di specificare dove Apigee deve cercare l'ID client. L'unica località valida che puoi impostare è quella predefinita, ovvero la variabile di flusso request.formparam.client_id. L'impostazione di ClientId su qualsiasi altra variabile non è supportata. Vedi anche Recuperare i token OAuth 2.0.

Predefinita:	request.formparam.client_id (un x-www-form-urlcodificato e specificato nel corpo della richiesta)
Presenza:	Facoltativo
Tipo:	String
Valori validi:	La variabile di flusso: request.formparam.client_id
Utilizzati con i tipi di autorizzazione:	authorization_code password implicito client_credentials Può essere utilizzato anche con l'operazione generateAuthorizationCode.

Elemento <Code>

<Code>request.queryparam.code</Code>

Nel flusso del tipo di concessione dell'autorizzazione, il client deve inviare un codice di autorizzazione al server di autorizzazione (Apigee). Questo elemento consente di specificare dove Apigee deve cercare il codice di autorizzazione. Ad esempio, potrebbe essere inviato come parametro di query, intestazione HTTP o parametro modulo (predefinito).

La variabile request.queryparam.auth_code indica che il codice di autorizzazione deve essere presente come parametro di query, ad esempio ?auth_code=AfGlvs9. Ad esempio, per richiedere il codice di autorizzazione in un'intestazione HTTP, imposta questo valore su request.header.auth_code. Vedi anche Recuperare i token OAuth 2.0.

Predefinita:	request.formparam.code (un x-www-form-urlcodificato e specificato nel corpo della richiesta)
Presenza:	facoltativo
Tipo:	String
Valori validi:	Qualsiasi variabile di flusso accessibile al criterio in fase di runtime
Utilizzati con i tipi di autorizzazione:	authorization_code

Elemento<TermsIn>

<ExpiresIn>10000</ExpiresIn>

Applica la scadenza dei token di accesso e dei codici di autorizzazione in millisecondi. (Per i token di aggiornamento, utilizza <RefreshTokenExpiresIn>.) Il valore della data di scadenza è un valore generato dal sistema più il valore <ExpiresIn>. Se <ExpiresIn> è impostato su -1, il token o il codice scade in base alla scadenza massima del token di accesso OAuth. Se <ExpiresIn> non viene specificato, il sistema applica un valore predefinito configurato a livello di sistema.

La data di scadenza può essere impostata anche in fase di runtime, utilizzando un valore predefinito hardcoded o facendo riferimento a una variabile di flusso. Ad esempio, puoi archiviare il valore di scadenza di un token in una mappa chiave-valore, recuperarlo, assegnarlo a una variabile e farvi riferimento nel criterio. Ad esempio, kvm.oauth.expires_in.

Apigee mantiene le seguenti entità nella cache per almeno 180 secondi dopo l'accesso alle entità.

• Token di accesso OAuth. Ciò significa che l'elemento ExpiresIn nel criterio OAuth v2 non potrà far scadere un token di accesso in meno di 180 secondi.
• Entità Key Management Service (KMS) (app, sviluppatori, prodotti API).
• Attributi personalizzati su token OAuth ed entità KMS.

La stanza seguente specifica una variabile di flusso e anche un valore predefinito. Tieni presente che il valore della variabile di flusso ha la precedenza sul valore predefinito specificato.

<ExpiresIn ref="kvm.oauth.expires_in">
    3600000 <!--default value in milliseconds-->
</ExpiresIn>

Apigee non supporta un modo per forzare la scadenza di un token dopo la sua creazione. Se devi forzare la scadenza del token (ad esempio, in base a una condizione), una possibile soluzione è descritta in questo post della community Apigee.

Per impostazione predefinita, i token di accesso scaduti vengono eliminati automaticamente dal sistema Apigee Apigee 3 giorni dopo la scadenza. Vedi anche Eliminazione dei token di accesso

Predefinita:	Se non specificato, il sistema applica un valore predefinito configurato a livello di sistema.
Presenza:	Facoltativo
Tipo:	Integer
Valori validi:	Qualsiasi numero intero positivo, nozero. Specifica la data di scadenza in millisecondi. Sebbene il valore di questo elemento sia in millisecondi, il valore impostato nella proprietà expires_in del token e nella variabile di flusso expires_in è espresso in secondi. -1 scadrà in base alla scadenza massima del token di accesso OAuth. Nota: se specifichi qualsiasi altro numero intero negativo o zero, si verifica un errore di deployment.
Utilizzati con i tipi di autorizzazione:	authorization_code implicito password client_credentials refresh_token Utilizzato anche con l'operazione generateAuthorizationCode.

Nota: tieni presente che se ScadeIn è impostato su -1, nel token generato vedrai il seguente valore di scadenza: "expires_in" : "0".

Elemento <ExternalAccessToken>

<ExternalAccessToken>request.queryparam.external_access_token</ExternalAccessToken>

Indica ad Apigee dove trovare un token di accesso esterno (un token di accesso non generato da Apigee).

La variabile request.queryparam.external_access_token indica che il token di accesso esterno deve essere presente come parametro di query, ad esempio ?external_access_token=12345678. Ad esempio, per richiedere il token di accesso esterno in un'intestazione HTTP, imposta questo valore su request.header.external_access_token. Consulta anche l'articolo sull'utilizzo di token OAuth di terze parti.

Elemento <ExternalAuthorization>

<ExternalAuthorization>true</ExternalAuthorization>

Se questo elemento è falso o non è presente, Apigee convalida normalmente client_id e client_secret rispetto all'archivio autorizzazioni Apigee. Utilizza questo elemento quando vuoi lavorare con i token OAuth di terze parti. Per maggiori dettagli sull'utilizzo di questo elemento, consulta l'articolo sull'utilizzo di token OAuth di terze parti.

Predefinita:	false
Presenza:	Facoltativo
Tipo:	Booleano
Valori validi:	vero o falso
Utilizzati con i tipi di autorizzazione:	authorization_code password client_credentials

Elemento <ExternalAuthorizationCode>

<ExternalAuthorizationCode>request.queryparam.external_auth_code</ExternalAuthorizationCode>

Indica ad Apigee dove trovare un codice di autorizzazione esterno (un codice di autenticazione non generato da Apigee).

La variabile request.queryparam.external_auth_code indica che il codice di autorizzazione esterno deve essere presente come parametro di query, ad esempio ?external_auth_code=12345678. Ad esempio, per richiedere il codice di autorizzazione esterno in un'intestazione HTTP, imposta questo valore su request.header.external_auth_code. Consulta anche l'articolo sull'utilizzo di token OAuth di terze parti.

Elemento <ExternalRefreshToken>

<ExternalRefreshToken>request.queryparam.external_refresh_token</ExternalRefreshToken>

Indica ad Apigee dove trovare un token di aggiornamento esterno (un token di aggiornamento non generato da Apigee).

La variabile request.queryparam.external_refresh_token indica che il token di aggiornamento esterno deve essere presente come parametro di query, ad esempio ?external_refresh_token=12345678. Ad esempio, per richiedere il token di aggiornamento esterno in un'intestazione HTTP, imposta questo valore su request.header.external_refresh_token. Consulta anche l'articolo sull'utilizzo di token OAuth di terze parti.

Elemento <GenerateResponse>

<GenerateResponse enabled='true'/>

Se impostato su true o se l'attributo enabled viene omesso, il criterio genera e restituisce una risposta. Ad esempio, per GeneraAccessToken, la risposta potrebbe essere simile a:

{
  "issued_at" : "1467841035013",
  "scope" : "read",
  "application_name" : "e31b8d06-d538-4f6b-9fe3-8796c11dc930",
  "refresh_token_issued_at" : "1467841035013",
  "status" : "approved",
  "refresh_token_status" : "approved",
  "api_product_list" : "[Product1, nhl_product]",
  "expires_in" : "1799",
  "developer.email" : "[e-mail]",
  "token_type" : "BearerToken",
  "refresh_token" : "rVSmm3QaNa0xBVFbUISz1NZI15akvgLJ",
  "client_id" : "Adfsdvoc7KX5Gezz9le745UEql5dDmj",
  "access_token" : "AnoHsh2oZ6EFWF4h0KrA0gC5og3a",
  "organization_name" : "cerruti",
  "refresh_token_expires_in" : "0",
  "refresh_count" : "0"
}

Se impostato su false o se l'elemento <GenerateResponse> viene omesso, non viene inviata alcuna risposta. Un insieme di variabili di flusso viene invece compilato con i valori correlati alla funzione del criterio. Ad esempio, una variabile di flusso denominata oauthv2authcode.OAuthV2-GenerateAuthorizationCode.code viene compilata con il codice di autorizzazione appena creato. Tieni presente che il valore di expires_in è espresso in secondi nella risposta.

Predefinita:	true
Presenza:	Facoltativo
Tipo:	string
Valori validi:	vero o falso
Utilizzati con i tipi di autorizzazione:	implicito password client_credentials refresh_token Può essere utilizzato anche con l'operazioneGenerateAuthorizationCode.

Elemento <GenerateErrorResponse>

<GenerateErrorResponse enabled='true'/>

Se impostato su true, il criterio genera e restituisce una risposta se l'attributo ContinueOnError è impostato su true. Se false (valore predefinito), non viene inviata alcuna risposta. Un insieme di variabili di flusso viene invece compilato con i valori correlati alla funzione del criterio.

Predefinita:	false
Presenza:	Facoltativo
Tipo:	string
Valori validi:	vero o falso
Utilizzati con i tipi di autorizzazione:	implicito password client_credentials refresh_token Può essere utilizzato anche con l'operazioneGenerateAuthorizationCode.

<GrantType>

<GrantType>request.queryparam.grant_type</GrantType>

Indica al criterio dove trovare il parametro del tipo di concessione passato in una richiesta. Secondo la specifica OAuth 2.0, il tipo di autorizzazione deve essere fornito con le richieste per i token di accesso e i codici di autorizzazione. La variabile può essere un'intestazione, un parametro di query o un parametro del modulo (impostazione predefinita).

Ad esempio request.queryparam.grant_type indica che la password deve essere presente come parametro di ricerca, come, ad esempio, ?grant_type=password. Ad esempio, per richiedere il tipo di autorizzazione in un'intestazione HTTP, imposta questo valore su request.header.grant_type. Vedi anche Recuperare i token OAuth 2.0.

Predefinita:	request.formparam.grant_type (un x-www-form-urlcodificato e specificato nel corpo della richiesta)
Presenza:	Facoltativo
Tipo:	string
Valori validi:	Una variabile, come spiegato in precedenza.
Utilizzati con i tipi di autorizzazione:	authorization_code password implicito client_credentials refresh_token

Elemento <Operation>

<Operation>GenerateAuthorizationCode</Operation>

L'operazione OAuth 2.0 eseguita dal criterio.

Predefinita:	Se <Operation> non è specificato, Apigee esamina l'elenco di <SupportedGrantTypes>. Solo le operazioni su questi tipi di concessioni avranno esito positivo. In altre parole, puoi omettere <Operation> se specifichi un <GrantType> nell'elenco <SupportedGrantTypes>. Se non vengono specificati né <Operation> né <SupportedGrantTypes>, il tipo di concessione predefinito è Authorization_code. In altre parole, le richieste del tipo di autorizzazione Authorization_code avranno esito positivo, mentre tutte le altre non andranno a buon fine.
Presenza:	Facoltativo
Tipo:	String
Valori validi:	GenerateAccessToken: genera un token di accesso. Vedi anche Recuperare i token OAuth 2.0. GenerateAccessTokenImplicitGrant: genera un token di accesso per il tipo di concessione implicita. Vedi anche Recuperare i token OAuth 2.0. GenerateAuthorizationCode: genera un codice di autorizzazione. Utilizzato con il tipo di concessione del codice di autorizzazione. Vedi anche Recuperare i token OAuth 2.0. RefreshAccessToken: scambia un token di aggiornamento con un nuovo token di accesso. Vedi anche Recuperare i token OAuth 2.0. VerifyAccessToken - Verifica che un token di accesso inviato in una richiesta sia valido. Guarda l'esempio di VerifyAccessToken riportato sopra e Verifica dei token di accesso. InvalidateToken: revoca un token di accesso. Dopo che un token è stato revocato, i client non possono utilizzarlo per chiamare un'API protetta. Vedi anche Approvare e revocare i token di accesso. Avviso : i token OAuth vengono memorizzati nella cache per tre minuti (180 secondi); pertanto, un token revocato potrebbe comunque avere esito positivo per un massimo di 3 minuti, fino alla scadenza del limite della cache. ValidateToken - ripristina o "approva" un token di accesso che è stato revocato in precedenza. Vedi anche Approvare e revocare i token di accesso. Operazioni aggiuntive del token di accesso JWT Se preferisci utilizzare token di accesso JWT anziché token di stringa opaca, sono disponibili anche le seguenti operazioni per la generazione e la convalida dei token JWT. Per maggiori dettagli, consulta Utilizzo delle operazioni del token OAuth JWT: GenerateJWTAccessToken: genera un token di accesso con un JWT firmato. Consulta Generazione di un token di accesso JWT. GenerateJWTAccessTokenImplicitGrant: genera un token di accesso con un JWT firmato per il tipo di concessione implicita. Consulta Generazione di un token di accesso JWT. VerifyJWTAccessToken - Verifica un token di accesso JWT firmato. Vedi anche Verificare un token di accesso JWT. RefreshJWTAccessToken: scambia un token di aggiornamento con un nuovo token di accesso JWT. Consulta anche l'articolo Aggiornare un token di accesso JWT.

Elemento <PassWord>

<PassWord>request.queryparam.password</PassWord>

Questo elemento viene utilizzato solo con il tipo di concessione della password. Con il tipo di autorizzazione della password, le credenziali utente (password e nome utente) devono essere rese disponibili per il criterio OAuthV2. Gli elementi <PassWord> e <UserName> vengono utilizzati per specificare le variabili in cui Apigee può trovare questi valori. Se questi elementi non vengono specificati, il criterio prevede di trovare i valori (per impostazione predefinita) nei parametri del modulo denominati username e password. Se i valori non vengono trovati, il criterio genera un errore. Puoi utilizzare gli elementi <PassWord> e <UserName> per fare riferimento a qualsiasi variabile di flusso contenente le credenziali.

Ad esempio, puoi passare la password in una richiesta di token utilizzando un parametro di query e impostare l'elemento in questo modo: <PassWord>request.queryparam.password</PassWord>. Per richiedere la password in un'intestazione HTTP, imposta questo valore su request.header.password.

Il criterio OAuthV2 non riguarda nessun altro con questi valori delle credenziali; Apigee sta semplicemente verificando che siano presenti. Spetta allo sviluppatore dell'API recuperare la richiesta di valori e inviarle a un provider di identità prima dell'esecuzione del criterio di generazione del token.

Vedi anche Recuperare i token OAuth 2.0.

Predefinita:	request.formparam.password (un x-www-form-urlcodificato e specificato nel corpo della richiesta)
Presenza:	Facoltativo
Tipo:	String
Valori validi:	Qualsiasi variabile di flusso disponibile per il criterio in fase di runtime.
Utilizzati con i tipi di autorizzazione:	password

<PrivateKey>/<Value>

<PrivateKey>
  <Value ref="variable-name-here"/>
</PrivateKey>

Fornisce la chiave privata utilizzata per verificare o firmare i token di accesso in formato JWT con un algoritmo RSA. Utilizza l'attributo ref per trasmettere la chiave in una variabile di flusso. Da utilizzare solo se il valore dell'elemento Algorithm è RS256, RS384 o RS512. Per maggiori informazioni, consulta Utilizzo delle operazioni del token OAuth JWT.

Nota : per proteggere i secret, come best practice conviene archiviare la chiave in un set di proprietà con ambito a livello di ambiente o in una mappa valori delle chiavi (KVM) con ambito a livello di ambiente. Vedi anche Accedere ai valori degli insiemi di proprietà e Utilizzare le mappe chiave-valore.

Predefinito	N/A
Presenza	Obbligatorio quando il valore dell'elemento Algorithm è uno tra HS256, HS384 o HS512.
Tipo	String
Valori validi	Una variabile di flusso contenente una stringa che rappresenta un valore di chiave privata RSA con codifica PEM.

<PublicKey>/<Value>

<PublicKey>
   <Value ref="variable-name-here"/>
</PublicKey>

Specifica la chiave pubblica o il certificato pubblico utilizzato per verificare la firma su un token di accesso in formato JWT firmato con un algoritmo RSA. Utilizza l'attributo ref per passare la chiave/certificata in una variabile di flusso. Da utilizzare solo se il valore dell'elemento Algorithm è RS256, RS384 o RS512.

Predefinito	N/A
Presenza	Per verificare un JWT firmato con un algoritmo RSA, devi utilizzare gli elementi Certificate, JWKS o Value.
Tipo	String
Valori validi	Una stringa o una variabile di flusso.

Elemento < RedirectUri>

<RedirectUri>request.queryparam.redirect_uri</RedirectUri>

Specifica dove Apigee deve cercare il parametro redirect_uri nella richiesta.

Informazioni sugli URI di reindirizzamento

Gli URI di reindirizzamento vengono utilizzati con il codice di autorizzazione e i tipi di concessioni implicite. L'URI di reindirizzamento indica al server di autorizzazione (Apigee) dove inviare un codice di autorizzazione (per il tipo di autorizzazione del codice di autorizzazione) o un token di accesso (per il tipo di concessione implicita). È importante capire quando questo parametro è obbligatorio, quando è facoltativo e come viene utilizzato:

• (Obbligatorio) Se nell'app sviluppatore è registrato un URL di callback nell'app per sviluppatori associato alle chiavi client della richiesta e se redirect_uri è presente nella richiesta, i due devono corrispondere esattamente. Se non corrispondono, viene restituito un errore. Per informazioni sulla registrazione di app per sviluppatori su Apigee e sulla specifica di un URL di callback, vedi Registrare app e gestire le chiavi API.

  Nota: per assicurarti che Apigee controlli una corrispondenza esatta tra "URL di callback" e "redirect_uri" (anziché una corrispondenza in avanti), imposta la seguente proprietà nella tua organizzazione: features.isStrictOAuthUriValidation = true. Il valore predefinito è false (corrispondenza in avanti).

  Contatta l'assistenza clienti Google Cloud per attivare la proprietà.

• (Facoltativo) Se è stato registrato un URL di callback e nella richiesta manca redirect_uri, Apigee reindirizza all'URL di callback registrato.
• (obbligatorio) Se un URL di callback non è registrato, redirect_uri è obbligatorio. Tieni presente che in questo caso Apigee accetterà QUALSIASI URL. Questa richiesta può presentare un problema di sicurezza, e pertanto deve essere utilizzata solo con app client attendibili. Se le app client non sono attendibili, la best practice consiste nel richiedere sempre la registrazione di un URL di callback.

Puoi inviare questo parametro in un parametro di query o in un'intestazione. La variabile request.queryparam.redirect_uri indica che RedirectUri deve essere presente come parametro di query, ad esempio ?redirect_uri=login.myapp.com. Ad esempio, per richiedere RedirectUri in un'intestazione HTTP, imposta questo valore su request.header.redirect_uri. Vedi anche Scaricare i token OAuth 2.0.

Predefinita:	request.formparam.redirect_uri (un x-www-form-urlcodificato e specificato nel corpo della richiesta)
Presenza:	Facoltativo
Tipo:	String
Valori validi:	Qualsiasi variabile di flusso accessibile nel criterio in fase di runtime
Utilizzati con i tipi di autorizzazione:	authorization_code implicito Utilizzato anche con l'operazione CreateAuthorizationCode.

Elemento <RefreshToken>

<RefreshToken>request.queryparam.refreshtoken</RefreshToken>

Quando richiedi un token di accesso utilizzando un token di aggiornamento, devi fornire il token di aggiornamento nella richiesta. Questo elemento consente di specificare dove Apigee deve cercare il token di aggiornamento. Ad esempio, potrebbe essere inviato come parametro di query, intestazione HTTP o parametro modulo (predefinito).

La variabile request.queryparam.refreshtoken indica che il token di aggiornamento deve essere presente come parametro di query, ad esempio ?refresh_token=login.myapp.com. Per richiedere UpdateToken in un'intestazione HTTP, ad esempio, imposta questo valore su request.header.refresh_token. Vedi anche Scaricare i token OAuth 2.0.

Predefinita:	request.formparam.refresh_token (un x-www-form-urlcodificato e specificato nel corpo della richiesta)
Presenza:	Facoltativo
Tipo:	String
Valori validi:	Qualsiasi variabile di flusso accessibile nel criterio in fase di runtime
Utilizzati con i tipi di autorizzazione:	refresh_token

Elemento <RefreshTokenScadeIn>

<RefreshTokenExpiresIn>1000</RefreshTokenExpiresIn>

Applica la scadenza dei token di aggiornamento in millisecondi. Il valore della data di scadenza è un valore generato dal sistema più il valore <RefreshTokenExpiresIn>. Se <RefreshTokenExpiresIn> è impostato su -1, il token di aggiornamento scade in base alla scadenza massima del token di aggiornamento OAuth. Se <RefreshTokenExpiresIn> non è specificato, il sistema applica il valore predefinito.

La data di scadenza può essere impostata anche in fase di runtime, utilizzando un valore predefinito hardcoded o facendo riferimento a una variabile di flusso. Ad esempio, puoi archiviare il valore di scadenza di un token in una mappa chiave-valore, recuperarlo, assegnarlo a una variabile e farvi riferimento nel criterio. Ad esempio, kvm.oauth.expires_in.

La stanza seguente specifica una variabile di flusso e anche un valore predefinito. Tieni presente che il valore della variabile di flusso ha la precedenza sul valore predefinito specificato.

<RefreshTokenExpiresIn ref="kvm.oauth.expires_in">
    86400000 <!--value in milliseconds-->
</RefreshTokenExpiresIn>

Predefinita:	2592000000 ms (30 giorni) (in vigore dal 31 maggio 2023)
Presenza:	Facoltativo
Tipo:	Integer
Valori validi:	Qualsiasi numero intero positivo, nozero. Specifica la scadenza in millisecondi. -1 scadrà in base alla scadenza massima del token di aggiornamento OAuth. Nota: se specifichi qualsiasi altro numero intero negativo o zero, si verifica un errore di deployment.
Utilizzati con i tipi di autorizzazione:	authorization_code password refresh_token

Nota: tieni presente che se UpdateTokenExpirationIn è impostato su -1, nel token generato vedrai il seguente valore di scadenza: "refresh_token_expires_in" : "0".

Elemento <ResponseType>

<ResponseType>request.queryparam.response_type</ResponseType>

Questo elemento indica ad Apigee il tipo di concessione richiesto dall'app client. Viene utilizzato solo con i flussi del codice di autorizzazione e del tipo di autorizzazione implicita.

Per impostazione predefinita, Apigee cerca il valore del tipo di risposta in un parametro di query response_type. Se vuoi eseguire l'override di questo comportamento predefinito, utilizza l'elemento <ResponseType> per configurare una variabile di flusso contenente il valore del tipo di risposta. Ad esempio, se imposti questo elemento su request.header.response_type, Apigee cerca il tipo di risposta da passare nell'intestazione della richiesta. Vedi anche Recuperare i token OAuth 2.0.

Predefinita:	request.formparam.response_type (un x-www-form-urlcodificato e specificato nel corpo della richiesta)
Presenza:	Facoltativo. Utilizza questo elemento se vuoi eseguire l'override del comportamento predefinito.
Tipo:	String
Valori validi:	code (per il tipo di concessione del codice di autorizzazione) o token (per il tipo di concessione implicita)
Utilizzati con i tipi di autorizzazione:	implicito Utilizzato anche con l'operazione CreateAuthorizationCode.

Elemento <ReuseRefreshToken>

<ReuseRefreshToken>true</ReuseRefreshToken>

Se impostato su true, il token di aggiornamento esistente viene riutilizzato fino alla scadenza. Se false, viene emesso un nuovo token di aggiornamento da Apigee quando viene presentato un token di aggiornamento valido.

Predefinita:	false
Presenza:	facoltativo
Tipo:	boolean
Valori validi:	true o false
Utilizzato con il tipo di autorizzazione:	refresh_token

Elemento <RFCCompliantRequestResponse>

<RFCCompliantRequestResponse>[true | false]</RFCCompliantRequestResponse>

Quando true, il criterio è conforme agli standard RFC6749 e attiva i seguenti comportamenti conformi:

• Le risposte di errore e non di errore includeranno il campo di intestazione della risposta Cache-Control HTTP per essere conforme a RFC2616 (Hypertext Transfer Protocol -- HTTP/1.1), con un valore no-store in qualsiasi risposta contenente token, credenziali o altre informazioni sensibili, nonché il campo di intestazione della risposta Pragma con valore no-cache.
• La proprietà expires_in sarà in formato alfanumerico. Per coerenza, anche il refresh_token_expires_in sarà alfanumerico.
• Le risposte OAuthV2 per la generazione di token includeranno il campo di intestazione Bearer conforme a RFC anziché BearerToken.
• I messaggi di errore nei payload di risposta saranno nel formato {"error" : "xxx", "error_description" :"yyy"} per gli errori del token di aggiornamento.

Nota: la RFC consente di inserire nella risposta del token parametri non menzionati nella specifica, pertanto non li rimuoveremo.

Predefinita:	false: per impostazione predefinita, il criterio consente alcuni comportamenti non conformi alla specifica RFC. Per maggiori dettagli, vedi Comportamento non compatibile con RFC. Imposta questo elemento su true per abilitare la conformità RFC.
Presenza:	Facoltativo
Tipo:	Booleano
Valori validi:	true o false
Utilizzati con i tipi di autorizzazione:	Tutti

<SecretKey>/<Value>

<SecretKey>
  <Value ref="your-variable-name"/>
</SecretKey>

Fornisce la chiave segreta utilizzata per verificare o firmare i token di accesso in formato JWT con un algoritmo HMAC. Utilizza solo se l'algoritmo è HS256, HS384 o HS512. Utilizza l'attributo ref per trasmettere la chiave in una variabile di flusso. Per maggiori informazioni, consulta Utilizzo delle operazioni del token OAuth JWT.

Apigee applica un'intensità minima della chiave per gli algoritmi HS256/HS384/HS512. La lunghezza minima della chiave per HS256 è di 32 byte, per HS384 è di 48 byte e per HS512 è di 64 byte. L'utilizzo di una chiave a potenza inferiore causa un errore di runtime.

Nota : per proteggere i secret, come best practice conviene archiviare la chiave in un set di proprietà con ambito a livello di ambiente o in una mappa valori delle chiavi (KVM) con ambito a livello di ambiente. Vedi anche Accedere ai valori degli insiemi di proprietà e Utilizzare le mappe chiave-valore.

Predefinito	N/A
Presenza	Obbligatorio per gli algoritmi HMAC.
Tipo	String
Valori validi	Una variabile di flusso

Elemento <Scope>

<Scope>request.queryparam.scope</Scope>

Se questo elemento è presente in uno dei criteri CreateAccessToken oGenerateAuthorizationCode, viene utilizzato per specificare gli ambiti in cui concedere il token o il codice. Questi valori vengono generalmente passati al criterio nella richiesta da un'app client. Puoi configurare l'elemento in modo che prenda una variabile di flusso, in modo da avere la possibilità di scegliere come vengono passati gli ambiti in una richiesta. Nell'esempio seguente, request.queryparam.scope indica che l'ambito deve essere presente come parametro di query, ad esempio ?scope=READ. Ad esempio, per richiedere l'ambito in un'intestazione HTTP, imposta questo valore su request.header.scope.

Se questo elemento viene visualizzato in un criterio "VerifyAccessToken", viene utilizzato per specificare gli ambiti che il criterio deve applicare. In questo tipo di criterio, il valore deve essere un nome di ambito impostato come hardcoded: non puoi utilizzare variabili. Ad esempio:

<Scope>A B</Scope>

Vedi anche Utilizzare gli ambiti OAuth2 e Recuperare i token OAuth 2.0.

Predefinita:	Nessun ambito
Presenza:	Facoltativo
Tipo:	String
Valori validi:	Se utilizzata con i criteri Genera*, una variabile di flusso. Se utilizzato con VerifyAccessToken, un elenco di nomi di ambiti (stringhe) separati da spazi.
Utilizzati con i tipi di autorizzazione:	authorization_code implicito password client_credentials Può essere utilizzato anche con le operazioni CreateAuthorizationCode e VerifyAccessToken.

Elemento <State>

<State>request.queryparam.state</State>

Nei casi in cui l'app client deve inviare le informazioni sullo stato al server di autorizzazione, questo elemento consente di specificare dove Apigee deve cercare i valori dello stato. Ad esempio, potrebbe essere inviato come parametro di query o in un'intestazione HTTP. Il valore dello stato viene in genere utilizzato come misura di sicurezza per prevenire gli attacchi CSRF.

Ad esempio request.queryparam.state indica che lo stato deve essere presente come parametro di query, come, ad esempio, ?state=HjoiuKJH32. Ad esempio, per richiedere lo stato in un'intestazione HTTP, imposta questo valore su request.header.state. Vedi anche Ottenere i token OAuth 2.0.

Predefinita:	Nessuno stato
Presenza:	Facoltativo
Tipo:	String
Valori validi:	Qualsiasi variabile di flusso accessibile al criterio in fase di runtime
Utilizzati con i tipi di autorizzazione:	Tutti Può essere utilizzato anche con l'operazione generateAuthorizationCode

Elemento <StoreToken>

 <StoreToken>true</StoreToken>

Imposta questo elemento su true quando l'elemento <ExternalAuthorization> è true. L'elemento <StoreToken> indica ad Apigee di archiviare il token di accesso esterno. In caso contrario, non sarà permanente.

Predefinita:	false
Presenza:	Facoltativo
Tipo:	Booleano
Valori validi:	vero o falso
Utilizzati con i tipi di autorizzazione:	authorization_code password client_credentials

Elemento <SupportedGrantTypes>/<GrantType>

<SupportedGrantTypes>
    <GrantType>authorization_code</GrantType>
    <GrantType>client_credentials</GrantType>
    <GrantType>implicit</GrantType>
    <GrantType>password</GrantType>
</SupportedGrantTypes>

Specifica i tipi di autorizzazione supportati da un endpoint del token OAuth su Apigee. Un endpoint potrebbe supportare più tipi di autorizzazione (ovvero, un singolo endpoint può essere configurato per distribuire i token di accesso per più tipi di autorizzazione). Per ulteriori informazioni sugli endpoint, consulta Informazioni sugli endpoint OAuth. Il tipo di concessione viene passato nelle richieste di token in un parametro grant_type.

Se non sono specificati tipi di autorizzazione supportati, gli unici tipi di autorizzazione consentiti sono authorization_code e implicit. Vedi anche l'elemento <GrantType> (un elemento di livello superiore utilizzato per specificare dove Apigee deve cercare il parametro grant_type che viene passato in una richiesta del client). Apigee si assicurerà che il valore del parametro grant_type corrisponda a uno dei tipi di concessioni supportati).

Predefinita:	autorizzazione _code e implicita
Presenza:	Obbligatorio
Tipo:	String
Valori validi:	client_credentials authorization_code password implicito

Elemento <Tokens>/<Token>

Utilizzato con le operazioni ConvalidaToken e InvalidateToken. Vedi anche Approvare e revocare i token di accesso. L'elemento <Token> identifica la variabile di flusso che definisce l'origine del token da revocare. Se gli sviluppatori dovrebbero inviare i token di accesso come parametri di ricerca denominati access_token, ad esempio, usa request.queryparam.access_token.

Elemento <UserName>

<UserName>request.queryparam.user_name</UserName>

Questo elemento viene utilizzato solo con il tipo di concessione della password. Con il tipo di autorizzazione della password, le credenziali utente (password e nome utente) devono essere rese disponibili per il criterio OAuthV2. Gli elementi <PassWord> e <UserName> vengono utilizzati per specificare le variabili in cui Apigee può trovare questi valori. Se questi elementi non vengono specificati, il criterio prevede di trovare i valori (per impostazione predefinita) nei parametri del modulo denominati username e password. Se i valori non vengono trovati, il criterio genera un errore. Puoi utilizzare gli elementi <PassWord> e <UserName> per fare riferimento a qualsiasi variabile di flusso contenente le credenziali.

Ad esempio, puoi passare il nome utente in un parametro di query e impostare l'elemento <UserName> in questo modo: <UserName>request.queryparam.username</UserName>.Per richiedere il nome utente in un'intestazione HTTP, imposta questo valore su request.header.username.

Il criterio OAuthV2 non riguarda nessun altro con questi valori delle credenziali; Apigee sta semplicemente verificando che siano presenti. Spetta allo sviluppatore dell'API recuperare la richiesta di valori e inviarle a un provider di identità prima dell'esecuzione del criterio di generazione del token.

Vedi anche Recuperare i token OAuth 2.0.

Predefinita:	request.formparam.username (un x-www-form-urlcodificato e specificato nel corpo della richiesta)
Presenza:	Facoltativo
Tipo:	String
Valori validi:	Qualsiasi impostazione di variabile.
Utilizzati con i tipi di autorizzazione:	password

Verifica dei token di accesso

Dopo aver configurato un endpoint token per un proxy API, al flusso che espone la risorsa protetta viene collegato un criterio OAuthV2 corrispondente che specifica l'operazione VerifyAccessToken.

Ad esempio, per garantire che tutte le richieste a un'API siano autorizzate, il seguente criterio applica la verifica dei token di accesso:

<OAuthV2 name="VerifyOAuthAccessToken">
  <Operation>VerifyAccessToken</Operation>
</OAuthV2>

Il criterio è associato alla risorsa API da proteggere. Per assicurarti che tutte le richieste a un'API siano verificate, collega il criterio al PreFlow della richiesta ProxyEndpoint come segue:

<PreFlow>
  <Request>
    <Step><Name>VerifyOAuthAccessToken</Name></Step>
  </Request>
</PreFlow>

I seguenti elementi facoltativi possono essere utilizzati per eseguire l'override delle impostazioni predefinite per l'operazione VerifyAccessToken.

Nome	Descrizione
Ambito	Un elenco di ambiti delimitati da spazi. La verifica avrà esito positivo se almeno uno degli ambiti elencati è presente nel token di accesso. Ad esempio, il seguente criterio controllerà il token di accesso per garantire che contenga almeno uno degli ambiti elencati. Se è presente READ o WRITE, la verifica andrà a buon fine. <OAuthV2 name="ValidateOauthScopePolicy"> <Operation>VerifyAccessToken</Operation> <Scope>READ WRITE</Scope> </OAuthV2>
AccessToken	La variabile in cui dovrebbe essere posizionato il token di accesso. Ad esempio request.queryparam.accesstoken. Per impostazione predefinita, in base alla specifica OAuth 2.0, il token di accesso deve essere presentato dall'app nell'intestazione HTTP Autorizzazione. Utilizza questa impostazione se il token di accesso deve essere presentato in una posizione non standard, ad esempio un parametro di query o un'intestazione HTTP con un nome diverso da Autorizzazione.

Vedi anche Verificare i token di accesso e Ottenere i token OAuth 2.0.

Specificare le posizioni delle variabili di richiesta

Per ogni tipo di autorizzazione, il criterio fa ipotesi sulla località o sulle informazioni richieste nei messaggi di richiesta. Queste ipotesi si basano sulla specifica OAuth 2.0. Se le tue app devono discostarsi dalla specifica OAuth 2.0, puoi specificare le località previste per ciascun parametro. Ad esempio, quando gestisci un codice di autorizzazione, puoi specificare la posizione del codice, l'ID client, l'URI di reindirizzamento e l'ambito. che possono essere specificati come intestazioni HTTP, parametri di ricerca o parametri del modulo.

L'esempio seguente mostra come specificare la posizione dei parametri del codice di autorizzazione richiesti come intestazioni HTTP:

  ...
  <GrantType>request.header.grant_type</GrantType>
  <Code>request.header.code</Code>
  <ClientId>request.header.client_id</ClientId>
  <RedirectUri>request.header.redirect_uri</RedirectUri>
  <Scope>request.header.scope</Scope>
  ...

In alternativa, se necessario per supportare la base di app client, puoi combinare intestazioni e parametri di query:

  ...
  <GrantType>request.header.grant_type</GrantType>
  <Code>request.header.code</Code>
  <ClientId>request.queryparam.client_id</ClientId>
  <RedirectUri>request.queryparam.redirect_uri</RedirectUri>
  <Scope>request.queryparam.scope</Scope>
  ...

È possibile configurare una sola località per parametro.

Variabili di flusso

Le variabili di flusso definite in questa tabella vengono compilate quando vengono eseguiti i rispettivi criteri OAuth e sono quindi disponibili per altri criteri o applicazioni in esecuzione nel flusso proxy API.

Operazione VerifyAccessToken

Quando viene eseguita l'operazione VerifyAccessToken, nel contesto di esecuzione del proxy viene compilata un numero elevato di variabili di flusso. Queste variabili forniscono proprietà correlate al token di accesso, all'app e allo sviluppatore. Puoi utilizzare un criterioAssignMessage o JavaScript, ad esempio, per leggere queste variabili e utilizzarle in base alle esigenze in una fase successiva del flusso. Queste variabili possono essere utili anche per il debug.

Nota: le variabili di prodotto API verranno compilate automaticamente se i prodotti API sono configurati con un ambiente, proxy e risorse API validi (derivanti da proxy.pathsuffix). Non è necessario impostare esplicitamente la variabile flow.resource.name.

Se i prodotti API non sono configurati con ambienti e proxy API validi, devi impostare esplicitamente flow.resource.name per compilare le variabili di prodotto API nel flusso. Per maggiori dettagli sulla configurazione del prodotto, consulta Gestire i prodotti basati su API.

Variabili specifiche per i token

Variabili	Descrizione
organization_name	Il nome dell'organizzazione su cui viene eseguito il proxy.
developer.id	L'ID dello sviluppatore o di AppGroup associato all'app client registrata.
developer.app.name	Il nome dello sviluppatore o dell'app AppGroup associata all'app client registrata.
client_id	L'ID client dell'app client registrata.
grant_type	Il tipo di concessione associato alla richiesta. Non supportato per l'operazione VerifyJWTAccessToken.
token_type	Il tipo di token associato alla richiesta.
access_token	Il token di accesso in fase di verifica.
accesstoken.{custom_attribute}	Un attributo personalizzato denominato nel token di accesso.
issued_at	La data di emissione del token di accesso espressa in tempo di epoca Unix in millisecondi.
expires_in	La scadenza del token di accesso. Espresso in secondi. Anche se l'elemento ExpiresIn imposta la scadenza in millisecondi, nella risposta del token e nelle variabili di flusso il valore viene espresso in secondi.
status	Lo stato del token di accesso (ad es. approvato o revocato).
scope	L'ambito (se presente) associato al token di accesso.
apiproduct.<custom_attribute_name>	Un attributo personalizzato denominato del prodotto API associato all'app client registrata.
apiproduct.name	Il nome del prodotto API associato all'app client registrata.
revoke_reason	(Solo Apigee hybrid) Indica perché il token di accesso è stato revocato. Non supportato per l'operazione VerifyJWTAccessToken. Il valore può essere REVOKED_BY_APP, REVOKED_BY_ENDUSER, REVOKED_BY_APP_ENDUSER o TOKEN_REVOKED.

Variabili specifiche per app

Queste variabili sono correlate all'app sviluppatore associata al token.

Variabili	Descrizione
app.name
app.id
app.accessType
app.callbackUrl
app.status	approvata o revocata
app.scopes
app.appFamily
app.apiproducts
app.appParentStatus
app.appType	Ad esempio: Sviluppatore
app.appParentId
app.created_by
app.created_at
app.last_modified_at
app.last_modified_by
app.{custom_attributes}	Un attributo personalizzato denominato dell'app client registrata.

Variabili specifiche per AppGroup

Le seguenti variabili di flusso contengono informazioni sull'AppGroup per il token e vengono compilate dal criterio. Questi attributi AppGroup vengono compilati solo se verifyapikey.{policy_name}.app.appType è "AppGroup".

Nota: se esegui la migrazione da Apigee Edge, le variabili di flusso aziendali sono disponibili automaticamente nell'attributo AppGroup corrispondente dopo la migrazione. Non sono necessarie modifiche ai bundle durante la migrazione.

Variabili	Descrizione
appgroup.displayName	Il nome visualizzato AppGroup.
appgroup.name	Nome dell'AppGroup.
appgroup.id	L'ID AppGroup. Nota: questo ID viene generato internamente da Apigee e non è garantito che rimanga invariato nel tempo. Non utilizzare la variabile appgroup.id per i seguenti scopi: Identificatore quota Chiavi KVM Identificatori inviati alle destinazioni da utilizzare nella logica di business del backend
appOwnerStatus	Lo stato del proprietario dell'app: "attivo", "non attivo" o "login_lock".
created_at	La data e l'ora di creazione dell'AppGroup.
created_by	L'indirizzo email dello sviluppatore che ha creato l'AppGroup.
last_modified_at	La data e l'ora dell'ultima modifica di AppGroup.
last_modified_by	L'indirizzo email dello sviluppatore che ha modificato l'ultima volta l'AppGroup.
{appgroup_custom_attributes}	Qualsiasi attributo AppGroup personalizzato. Specifica il nome dell'attributo personalizzato.

Variabili specifiche per sviluppatori

Se il campo app.appType è "Sviluppatore", gli attributi sviluppatore vengono compilati.

Variabili	Descrizione
Variabili specifiche per sviluppatori
developer.id
developer.userName
developer.firstName
developer.lastName
developer.email
developer.status	attivo o non attivo
developer.apps
developer.created_by
developer.created_at
developer.last_modified_at
developer.last_modified_by
developer.{custom_attributes}	Un attributo personalizzato denominato dello sviluppatore.

Operazione generaAuthorizationCode

Queste variabili vengono impostate quando l'operazione generaAuthorizationCode viene eseguita correttamente:

Prefisso: oauthv2authcode.{policy_name}.{variable_name}

Esempio: oauthv2authcode.GenerateCodePolicy.code

Variabile	Descrizione
code	Il codice di autorizzazione generato durante l'esecuzione del criterio.
redirect_uri	L'URI di reindirizzamento associato all'app client registrata.
scope	L'ambito OAuth facoltativo passato nella richiesta del client.
client_id	L'ID client trasmesso nella richiesta del client.

Operazioni generateAccessToken e RefreshAccessToken

Queste variabili vengono impostate quando le operazioniGenerateAccessToken e RefreshAccessToken vengono eseguite correttamente. Tieni presente che le variabili del token di aggiornamento non si applicano al flusso del tipo di concessione delle credenziali client.

Prefisso: oauthv2accesstoken.{policy_name}.{variable_name}

Esempio: oauthv2accesstoken.GenerateTokenPolicy.access_token

Nome variabile	Descrizione
access_token	Il token di accesso generato.
client_id	L'ID client dell'app sviluppatore associata a questo token.
expires_in	Il valore di scadenza del token. Consulta l'elemento <ExpiresIn> per i dettagli. Tieni presente che nella risposta, expires_in è espresso in secondi.
scope	Elenco degli ambiti disponibili configurati per il token. Vedi Utilizzo degli ambiti OAuth2.
status	approved o revoked.
token_type	È impostato su BearerToken.
developer.email	L'indirizzo email dello sviluppatore registrato proprietario dell'app sviluppatore associata al token.
organization_name	L'organizzazione in cui viene eseguito il proxy.
api_product_list	Un elenco dei prodotti associati all'app sviluppatore corrispondente del token.
refresh_count
refresh_token	Il token di aggiornamento generato. Tieni presente che i token di aggiornamento non vengono generati per il tipo di concessione delle credenziali client.
refresh_token_expires_in	La durata del token di aggiornamento, in secondi.
refresh_token_issued_at	Questo valore di tempo è la rappresentazione stringa della quantità di timestamp a 32 bit corrispondente. Ad esempio, "Mer, 21 ago 2013 19:16:47 UTC" corrisponde al valore del timestamp 1377112607413.
refresh_token_status	approved o revoked.

GenerateAccessTokenImplicitGrant

Queste variabili vengono impostate quando l'operazione GeneraAccessTokenImplicit viene eseguita correttamente per il flusso del tipo di concessione implicito.

Prefisso: oauthv2accesstoken.{policy_name}.{variable_name}

Esempio: oauthv2accesstoken.RefreshTokenPolicy.access_token

Variabile	Descrizione
oauthv2accesstoken.access_token	Il token di accesso generato durante l'esecuzione del criterio.
oauthv2accesstoken.{policy_name}.expires_in	Il valore di scadenza del token, espresso in secondi. Per informazioni dettagliate, consulta l'elemento <ExpiresIn>.

Informazioni sugli errori

This section describes the fault codes and error messages that are returned and fault variables that are set by Apigee when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Fault code	HTTP status	Cause	Thrown by operations
steps.oauth.v2.access_token_expired	401	The access token is expired.	VerifyAccessToken InvalidateToken
steps.oauth.v2.access_token_not_approved	401	The access token was revoked.	VerifyAccessToken
steps.oauth.v2.apiresource_doesnot_exist	401	The requested resource does not exist any of the API products associated with the access token.	VerifyAccessToken
steps.oauth.v2.FailedToResolveAccessToken	500	The policy expected to find an access token in a variable specified in the <AccessToken> element, but the variable could not be resolved.	GenerateAccessToken
steps.oauth.v2.FailedToResolveAuthorizationCode	500	The policy expected to find an authorization code in a variable specified in the <Code> element, but the variable could not be resolved.	GenerateAuthorizationCode
steps.oauth.v2.FailedToResolveClientId	500	The policy expected to find the Client ID in a variable specified in the <ClientId> element, but the variable could not be resolved.	GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken
steps.oauth.v2.FailedToResolveRefreshToken	500	The policy expected to find a refresh token in a variable specified in the <RefreshToken> element, but the variable could not be resolved.	RefreshAccessToken
steps.oauth.v2.FailedToResolveToken	500	The policy expected to find a token in a variable specified in the <Tokens> element, but the variable could not be resolved.	ValidateToken InvalidateToken
steps.oauth.v2.InsufficientScope	403	The access token presented in the request has a scope that does not match the scope specified in the verify access token policy. To learn about scope, see Working with OAuth2 scopes.	VerifyAccessToken
steps.oauth.v2.invalid_access_token	401	The access token sent from the client is invalid.	VerifyAccessToken
steps.oauth.v2.invalid_client	401	This error name is returned when the <GenerateResponse> property of the policy is set to true and the client ID sent in the request is invalid. Check to be sure you are using the correct client key and secret values for the Developer App associated with your proxy. Typically, these values are sent as a Base64 encoded Basic Authorization header. Note: It is recommended that you change existing fault rule conditions to catch both the invalid_client and InvalidClientIdentifier names.	GenerateAccessToken RefreshAccessToken
steps.oauth.v2.invalid_request	400	This error name is used for multiple different kinds of errors, typically for missing or incorrect parameters sent in the request. If <GenerateResponse> is set to false, use fault variables (described below) to retrieve details about the error, such as the fault name and cause.	GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken
steps.oauth.v2.InvalidAccessToken	401	The authorization header does not have the word Bearer, which is required. For example: Authorization: Bearer your_access_token	VerifyAccessToken
steps.oauth.v2.InvalidAPICallAsNo\ ApiProductMatchFound	401	The currently executing API proxy or operation is not in the Product associated with the access token. Tips: Be sure that the product associated with the access token is configured correctly. For example, if you use wildcards in resource paths, be sure the wildcards are being used correctly. See Managing API products for details. See also Oauth2.0 Access Token Verification throws "Invalid API call as no apiproduct match found" error for more guidance on causes for this error.	VerifyAccessToken
steps.oauth.v2.InvalidClientIdentifier	500	This error name is returned when the <GenerateResponse> property of the policy is set to false and the client ID sent in the request is invalid. Check to be sure you are using the correct client key and secret values for the Developer App associated with your proxy. Typically, these values are sent as a Base64 encoded Basic Authorization header. Note: It is recommended that you change existing fault rule conditions to catch both the invalid_client and InvalidClientIdentifier names.	GenerateAccessToken RefreshAccessToken
steps.oauth.v2.InvalidParameter	500	The policy must specify either an access token or an authorization code, but not both.	GenerateAuthorizationCode GenerateAccessTokenImplicitGrant
steps.oauth.v2.InvalidTokenType	500	The <Tokens>/<Token> element requires you to specify the token type (for example, refreshtoken). If the client passes the wrong type, this error is thrown.	ValidateToken InvalidateToken
steps.oauth.v2.MissingParameter	500	The response type is token, but no grant types are specified.	GenerateAuthorizationCode GenerateAccessTokenImplicitGrant
steps.oauth.v2.UnSupportedGrantType	500	The client specified a grant type that is unsupported by the policy (not listed in the <SupportedGrantTypes> element). Note: There is currently a bug where unsupported grant type errors are not thrown correctly. If an unsupported grant type error occurs, the proxy does not enter the Error Flow, as expected.	GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken

JWT token-specific runtime errors

Runtime error codes and descriptions for JWT auth token flows depend on the OAuth2 flow context:

• If the flow context is token generation or refresh, see Error codes for JWT token generation and refresh flows below.
• For the token verification flow, see Error codes for token verification flows below.

Error codes for JWT token generation and refresh flows

For OAuth2 flows that generate or refresh JWT tokens, error responses adhere to the error responses specified in RFC6749. For details, see Section 5.2 Error Response.

Error codes for the token verification flow

The error codes listed in the following table apply to VerifyAccessToken operation only.

Fault code	HTTP status	Cause	Thrown by operations
oauth.v2.JWTSigningFailed	401	The policy was unable to sign the JWT.	GenerateJWTAccessToken
oauth.v2.InvalidValueForJWTAlgorithm	401	This occurs when the algorithm is not present in the JWT access token or when the value is not supported.	GenerateJWTAccessToken VerifyJWTAccessToken
oauth.v2.InsufficientKeyLength	401	In Generation of JWT, for a key less than the minimum size for the HS384 or HS512 algorithms	GenerateJWTAccessToken VerifyJWTAccessToken
oauth.v2.JWTAlgorithmMismatch	401	The algorithm specified in the Generate policy did not match the one expected in the Verify policy. The algorithms specified must match.	VerifyJWTAccessToken
oauth.v2.JWTDecodingFailed	401	The policy was unable to decode the JWT. The JWT is possibly corrupted.	VerifyJWTAccessToken
oauth.v2.MissingMandatoryClaimsInJWT	401	Occurs when the required claims are not present in the Jwt Access token	VerifyJWTAccessToken
oauth.v2.InvalidJWTSignature	401	This occurs when the signature of JWT access token could not be verified or when the signature is invalid.	VerifyJWTAccessToken
oauth.v2.InvalidTypeInJWTHeader	401	Occurs when the JWT's type is not at+Jwt	VerifyJWTAccessToken

Deployment errors

These errors can occur when you deploy a proxy containing this policy.

Error name	Cause
InvalidValueForExpiresIn	For the <ExpiresIn> element, valid values are positive integers and -1.
InvalidValueForRefreshTokenExpiresIn	For the <RefreshTokenExpiresIn> element, valid values are positive integers and -1.
InvalidGrantType	An invalid grant type is specified in the <SupportedGrantTypes> element. See the policy reference for a list of valid types.
ExpiresInNotApplicableForOperation	Be sure that the operations specified in the <Operations> element support expiration. For example, the VerifyToken operation does not.
RefreshTokenExpiresInNotApplicableForOperation	Be sure that the operations specified in the <Operations> element support refresh token expiration. For example, the VerifyToken operation does not.
GrantTypesNotApplicableForOperation	Be sure that the grant types specified in <SupportedGrantTypes> are supported for the specified operation.
OperationRequired	You must specify an operation in this policy using the <Operation> element. Note: If the <Operation> element is missing, the UI throws a schema validation error.
InvalidOperation	You must specify a valid operation in this policy using the <Operation> element. Note: If the <Operation> element is invalid, the UI throws a schema validation error.
TokenValueRequired	You must specify a token <Token> value in the <Tokens> element.

JWT token-specific deployment errors

These deployment errors are specific to policies that use JWT token operations.

Error name	Cause
InvalidValueForAlgorithm	The algorithm specified in the <Algorithm> element is not among the list of available algorithms or is not present.
MissingKeyConfiguration	The required <SecretKey>, <PrivateKey>, or <PublicKey> elements are missing, depending on which algorithm is used.
EmptyValueElementForKeyConfiguration	The required child element <Value> is not defined in the <PrivateKey>, <PublicKey>, or <SecretKey> elements
InvalidKeyConfiguration	The <PrivateKey> element is not used with RSA family algorithms or the <SecretKey> element is not used with HS Family algorithms.
EmptyRefAttributeForKeyconfiguration	The ref attribute of the child element <Value> of the <PrivateKey>, <PublicKey> or <SecretKey> elements is empty.
InvalidVariableNameForKey	The flow variable name specified in the ref attribute of the child element <Value> of the <PrivateKey>, <PublicKey> or <SecretKey> elements does not contain the private prefix.

Fault variables

These variables are set when this policy triggers an error at runtime.

Note: You an use these variables to create Fault Rule conditions. These variables are populated when an error occurs if <GenerateResponse> is set to false. If <GenerateResponse> is true, the policy returns a response to the client immediately if an error occurs -- the error flow is skipped and these variables are not populated. For more information, see What you need to know about policy errors.

Variables	Where	Example
fault.name="fault_name"	fault_name is the name of the fault, as listed in the Runtime errors table above. The fault name is the last part of the fault code.	fault.name = "invalid_request"
oauthV2.policy_name.failed	policy_name is the user-specified name of the policy that threw the fault.	oauthV2.GenerateAccesstoken.failed = true
oauthV2.policy_name.fault.name	policy_name is the user-specified name of the policy that threw the fault.	oauthV2.GenerateAccesstoken.fault.name = invalid_request Note: For the VerifyAccessToken operation, the fault name includes this suffix: keymanagement.service For example: keymanagement.service.invalid_access_token
oauthV2.policy_name.fault.cause	policy_name is the user-specified name of the policy that threw the fault.	oauthV2.GenerateAccesstoken.cause = Required param : grant_type

Example error response

These responses are sent back to the client if the <GenerateResponse> element is true.

Note: For error handling, the best practice is to trap the errorcode part of the error response. Do not rely on the text in the faultstring, because it could change.

If <GenerateResponse> is true, the policy returns errors in this format for operations that generate tokens and codes. For a complete list, see see OAuth HTTP error response reference.

{"ErrorCode" : "invalid_client", "Error" :"ClientId is Invalid"}

If <GenerateResponse> is true, the policy returns errors in this format for verify and validate operations. For a complete list, see see OAuth HTTP error response reference.

{  
   {  
      "fault":{  
         "faultstring":"Invalid Access Token",
         "detail":{  
            "errorcode":"keymanagement.service.invalid_access_token"
         }
      }
   }

Example fault rule

<FaultRule name="OAuthV2 Faults">
    <Step>
        <Name>AM-InvalidClientResponse</Name>
        <Condition>(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")</Condition>
    </Step>
    <Step>
        <Name>AM-InvalidTokenResponse</Name>
        <Condition>(fault.name = "invalid_access_token")</Condition>
    </Step>
    <Condition>(oauthV2.failed = true) </Condition>
</FaultRule>

I token in Storage sono sottoposti ad hashing

Se utilizzi Apigee hybrid o Apigee, i token di accesso e i token di aggiornamento OAuthV2 vengono sottoposti ad hashing per impostazione predefinita se archiviati nel database Cassandra del runtime. L'hashing previene l'utilizzo dei token in caso di compromissione del database.

Utilizzo della configurazione OAuth predefinita

A ogni organizzazione (anche in prova gratuita) su Apigee viene eseguito il provisioning di un endpoint token OAuth. L'endpoint è preconfigurato con criteri nel proxy API chiamato oauth. Puoi iniziare a utilizzare l'endpoint token non appena crei un account su Apigee. Per maggiori dettagli, consulta la pagina Informazioni sugli endpoint OAuth.

Eseguire l'eliminazione definitiva dei token di accesso

Per impostazione predefinita, i token OAuth2 vengono eliminati definitivamente dal sistema Apigee 3 giorni (259.200 secondi) dopo la scadenza sia del token di accesso sia del token di aggiornamento (se esistente).

Comportamento non conforme a RFC

Per impostazione predefinita, il criterio OAuthV2, con l'operazione GeneraAccessToken, restituisce una risposta del token che contiene alcune proprietà non conformi a RFC. La seguente tabella mostra le proprietà non conformi restituite dal criterio OAuthV2 e le proprietà conformi corrispondenti.

Nota: se è necessaria la conformità di questi elementi, imposta l'elemento RFCCompliantRequestResponse su true

OAuthV2 restituisce:	La proprietà conforme alla specifica RFC è:
"token_type":"BearerToken"	"token_type":"Bearer"
"expires_in":"3600"	"expires_in":3600 Il valore conforme è un numero, non una stringa.

Inoltre, la risposta di errore per un token di aggiornamento scaduto quando grant_type = refresh_token:

{"ErrorCode" : "invalid_request", "Error" :"Refresh Token expired"}

Tuttavia, la risposta conforme alla specifica RFC è:

{"error" : "invalid_grant", "error_description" :"refresh token expired"}

Argomenti correlati

• Introduzione a OAuth 2.0