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

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X.
informazioni

Apigee Edge fornisce il framework OAuth 2.0 per proteggere le API. OAuth2 è uno degli schemi di autenticazione e autorizzazione basati su token open standard più diffusi. Consente alle applicazioni client di accedere alle API per conto degli utenti senza che questi debbano divulgare nome utente e password.

Apigee Edge consente agli sviluppatori di generare token di accesso e/o aggiornamento implementando uno qualsiasi dei quattro tipi di autorizzazione OAuth2 (credenziali client, password, impliciti 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 data di scadenza, che può essere impostata nel criterio OAuthv2.

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

Questo antipattern è correlato all'anti-pattern dell'impostazione di una scadenza lunga per i token OAuth.

Antipattern

L'impostazione di una scadenza per un token di aggiornamento nel criterio OAuthv2 comporta l'accumulo di token OAuth e un maggiore utilizzo di spazio su disco sui nodi Cassandra.

Il criterio OAuthV2 di esempio seguente 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 precedente:

  • Per il token di accesso è impostato un tempo di scadenza di 30 minuti ragionevolmente basso.
  • La scadenza del token di aggiornamento non è impostata.
  • Il token di aggiornamento persiste per sempre nel datastore (Cassandra), causando l'accumulo dei dati.
  • Un token di aggiornamento generato senza scadenza può essere utilizzato a tempo indeterminato per generare token di accesso.
  • Se il traffico verso questa API è di 10 richieste al secondo, l'API può generare fino a 864.000 token in un giorno.

Impatto

  • Se il token di aggiornamento viene creato senza scadenza, ci sono due conseguenze principali:
    • Puoi utilizzare il token di aggiornamento in qualsiasi momento in futuro, possibilmente per anni, per ottenere un token di accesso. Questo può avere implicazioni per la sicurezza.
    • La riga in Cassandra contenente il token di aggiornamento non verrà mai eliminata. In questo modo, i dati si accumuleranno in Cassandra.
  • Se non utilizzi il token di aggiornamento per ottenere un nuovo token di accesso, ma crei invece un nuovo token di aggiornamento e un token di accesso, il token di aggiornamento precedente rimarrà in Cassandra. Di conseguenza, i token di aggiornamento continueranno ad accumularsi in Cassandra, aggiungendo ulteriori bloat, aumentando l'utilizzo del disco e compattazioni più consistenti, causando infine latenze di lettura/scrittura in Cassandra.

Best practice

Utilizza una scadenza appropriatamente ridotta sia per i token di aggiornamento che per i token di accesso. Consulta le best practice per impostare i tempi di scadenza dei token di aggiornamento e di accesso. Assicurati di specificare una configurazione di scadenza sia per l'accesso che per il token di aggiornamento nel criterio. Per ulteriori dettagli sulla configurazione dei criteri, consulta la documentazione relativa ai criteri OAuthV2.

Best practice specifiche per i clienti Edge per Cloud privato

La sezione descrive le best practice specifiche per i clienti di Edge per Cloud privato.

Specifica una scadenza predefinita del token di aggiornamento

Per impostazione predefinita, se la scadenza del token di aggiornamento non è specificata nella configurazione di un criterio, Edge crea un token di aggiornamento senza scadenza. Puoi ignorare questo comportamento mediante la procedura riportata di seguito:

  1. Su un nodo del processore dei 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 riga seguente al file:
    conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000
    In questo modo la scadenza predefinita del token di aggiornamento, se non è specificata in un criterio, verrà impostata su 1 ora. Puoi modificare questo valore predefinito in base alle tue esigenze aziendali.
  3. Riavvia il servizio Message processor:
    apigee-service edge-message-processor restart
  4. Ripeti i passaggi precedenti in tutti i nodi del processore dei messaggi uno alla volta.

Best practice in Cassandra

Prova a eseguire l'upgrade all'ultima versione di Apigee disponibile pubblicamente. Apigee continua a rilasciare correzioni e miglioramenti che continuano a migliorare e ottimizzare la gestione dei token all'interno di Apigee. In Apigee, i token di accesso e di aggiornamento sono archiviati in Cassandra all'interno dello spazio delle chiavi dei "km". Devi assicurarti che la strategia di compattazione di questo spazio delle chiavi sia impostata 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 valore predefinito di 10 giorni a un valore più basso (ad esempio 3 giorni) per garantire che gli elementi tombali generati a causa dell'eliminazione dei token vengano eliminati più rapidamente dal datastore.

Per approfondire