Anti-pattern: non impostare una scadenza per i token OAuth

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

Apigee Edge fornisce il framework OAuth 2.0 per le API sicure. OAuth2 è uno dei più diffusi sistemi di autenticazione basati su token e schemi di autorizzazione. Consente alle applicazioni client di accedere alle API per conto degli utenti senza richiedere agli utenti di divulgare il proprio nome utente e la propria password.

Apigee Edge consente agli sviluppatori di generare token di accesso e/o aggiornamento implementando uno qualsiasi dei i quattro tipi di autorizzazione OAuth2: credenziali client, password, implicit e codice di autorizzazione - utilizzando il criterio OAuthv2. Le applicazioni client utilizzano i token di accesso per consumare API sicure. Ogni token di accesso ha una propria scadenza che può essere impostato nel criterio OAuthv2.

I token di aggiornamento vengono emessi facoltativamente insieme ai token di accesso con alcuni dei tipi di autorizzazione. Aggiorna Vengono utilizzati per ottenere nuovi token di accesso validi dopo che il token di accesso originale è scaduto revocata. La scadenza dei token di aggiornamento può essere impostata anche nel criterio OAuthv2.

Questo anti-pattern è correlato all'anti-pattern impostare una scadenza lunga per i token OAuth.

Antipattern

Impostazione di nessuna scadenza per un token di aggiornamento nel criterio OAuthv2 porta all'accumulo di token OAuth e a un maggiore utilizzo di spazio su disco nei nodi Cassandra.

Il seguente criterio OAuthV2 di esempio mostra una configurazione mancante per <RefreshTokenExpiresIn>:

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

Nell'esempio riportato sopra:

  • Il token di accesso è impostato con una scadenza ragionevolmente bassa di 30 minuti.
  • La scadenza del token di aggiornamento non è impostata.
  • Il token di aggiornamento persiste per sempre nel datastore (Cassandra) causando dati accumulo.
  • Un token di aggiornamento creato senza scadenza può essere utilizzato all'infinito per generare token di accesso.
  • Se il traffico verso questa API è di 10 richieste al secondo, può generare fino a 864.000 token tra un giorno.

Impatto

  • Se il token di aggiornamento viene creato senza scadenza, ci sono due conseguenze principali:
    • Il token di aggiornamento può essere utilizzato in qualsiasi momento futuro, possibilmente per anni, per ottenere un accesso di accesso. Ciò può avere implicazioni per la sicurezza.
    • La riga di Cassandra contenente il token di aggiornamento non verrà mai eliminata. Ciò comporterà l'accumulo dei dati in Cassandra.
  • Se non utilizzi il token di aggiornamento per ottenere un nuovo token di accesso, ma creare un nuovo token di aggiornamento e un nuovo token di accesso, il token di aggiornamento precedente rimarrà in Cassandra. Di conseguenza, aggiorna continueranno ad accumularsi in Cassandra, aumentando ulteriormente il numero di maggiore utilizzo del disco, compattazioni più pesanti e alla fine causerà operazioni di lettura/scrittura e la latenza minima in Cassandra.

Best practice

Usa una scadenza opportunamente ridotta sia per i token di aggiornamento sia per i token di accesso. Consulta best practice per impostare la scadenza di aggiornamento e i token di accesso. Assicurati di specificare una configurazione per la scadenza per entrambi gli accessi e aggiorna il token nel criterio. Consulta le Documentazione sui criteri OauthV2 per ulteriori dettagli sulla configurazione dei criteri.

Best practice specifiche per i clienti Edge per il cloud privato

La sezione descrive le best practice specifiche per i clienti Edge per il cloud privato.

Specifica una scadenza predefinita per il token di aggiornamento

Per impostazione predefinita, se la scadenza di un token di aggiornamento non è specificata in una configurazione di criteri, Edge crea un token di aggiornamento senza scadenza. Puoi ignorare questo comportamento la seguente procedura:

  1. Su un nodo del processore di messaggi, modifica o crea il file di override della configurazione $APIGEE_ROOT/customer/application/message-processor.properties. Assicurati che questo file sia leggibile dall'utente apigee.
  2. Aggiungi la seguente riga al file:
    conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000
    Se non viene specificato in un criterio, la scadenza predefinita del token di aggiornamento verrà impostata su 1 ora. Puoi modificare questo valore predefinito in base alle tue esigenze aziendali.
  3. Riavvia il servizio di processore di messaggi:
    apigee-service edge-message-processor restart
  4. Ripeti i passaggi precedenti in tutti i nodi del processore di messaggi uno alla volta.
di Gemini Advanced. di Gemini Advanced.

Best practice in Cassandra

Prova a eseguire l'upgrade alla versione più recente di Apigee disponibile pubblicamente. Apigee continua alle correzioni di rilascio e ai miglioramenti che continuano a migliorare e ottimizzare la gestione di token in Apigee. In Apigee, i token di accesso e di aggiornamento sono archiviati in Cassandra nello spazio delle chiavi "kms". Occorre assicurare che la strategia di compattazione lo spazio delle chiavi è impostato su LeveledCompactionStrategy. Controlla che i seguenti indici non siano presenti:
    .
  • kms.oauth_20_access_tokens.oauth_20_access_tokens_organization_name_idx#f0f0f0 e
  • kms.oauth_20_access_tokens.oauth_20_access_tokens_status_idx

Puoi anche ridurre gc_grace_seconds nella tabella kms.oauth_20_access_tokens dal periodo predefinito di 10 giorni a un periodo inferiore (ad esempio, 3 giorni) per garantire che i tombstone generati a causa dell'eliminazione dei token vengano vengono eliminati definitivamente dal datastore.

Per approfondire