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

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

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

Apigee Edge consente agli sviluppatori di generare token di accesso e/o di aggiornamento implementando uno dei quattro tipi di concessione OAuth2 - credenziali client, password, implicita, e codice di autorizzazione - utilizzando la policy OAuthv2. Le applicazioni client utilizzano i token di accesso per utilizzare le API sicure. Ogni token di accesso ha un proprio periodo di scadenza, che può essere impostato nella policy OAuthv2.

I token di aggiornamento vengono emessi facoltativamente insieme ai token di accesso con alcuni dei tipi di concessione. I token di aggiornamento vengono utilizzati per ottenere nuovi token di accesso validi dopo la scadenza o la revoca del token di accesso originale. Il periodo di scadenza dei token di aggiornamento può essere impostato anche nella policy OAuthv2.

Questo antipattern è correlato all'antipattern dell' impostazione di un periodo di scadenza lungo per i token OAuth.

Antipattern

Se non imposti un periodo di scadenza per un token di aggiornamento nella policy OAuthv2 , i token OAuth si accumulano e l'utilizzo dello spazio su disco sui nodi Cassandra aumenta.

La seguente policy 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 sopra riportato:

• Il token di accesso è impostato con un periodo di scadenza ragionevolmente basso di 30 minuti.
• La scadenza del token di aggiornamento non è impostata.
• Il token di aggiornamento persiste nel datastore (Cassandra) per sempre, causando l'accumulo di 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, può generare fino a 864.000 token in un giorno.

Impatto

• Se il token di aggiornamento viene creato senza scadenza, si verificano due conseguenze principali:
  • Il token di aggiornamento può essere utilizzato in qualsiasi momento in futuro, possibilmente per anni, per ottenere un token di accesso token. Ciò può avere implicazioni per la sicurezza.
  • La riga in Cassandra contenente il token di aggiornamento non verrà mai eliminata. Ciò causerà l'accumulo di dati in Cassandra.
• Se non utilizzi il token di aggiornamento per ottenere un nuovo token di accesso, ma crei un nuovo token di aggiornamento e un nuovo token di accesso, il token di aggiornamento precedente rimarrà in Cassandra. Di conseguenza, i token di aggiornamento continueranno ad accumularsi in Cassandra, aumentando ulteriormente il volume, l'utilizzo del disco e le compattazioni più pesanti, e alla fine causeranno latenze di lettura/scrittura in Cassandra.

Best practice

Utilizza un periodo di scadenza adeguatamente basso sia per i token di aggiornamento sia per i token di accesso. Consulta le best practice per l'impostazione dei periodi di scadenza dei token di aggiornamento e di accesso. Assicurati di specificare una configurazione di scadenza sia per il token di accesso sia per il token di aggiornamento nella policy. Per ulteriori dettagli sulla configurazione delle policy, consulta la documentazione della policy OauthV2.

Best practice specifiche per i clienti di Edge for Private Cloud

Questa sezione descrive le best practice specifiche per i clienti di Edge for Private Cloud.

Specificare una scadenza predefinita per il token di aggiornamento

Per impostazione predefinita, se non viene specificata una scadenza del token di aggiornamento in una configurazione della policy, Edge crea un token di aggiornamento senza scadenza. Puoi eseguire l'override di questo comportamento seguendo questa 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

   In questo modo, se non viene specificata una policy, la scadenza predefinita del token di aggiornamento verrà impostata su 1 ora. Puoi modificare questo valore predefinito in base alle esigenze della tua attività.
3. Riavvia il servizio del 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.

Best practice in Cassandra

• 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 inferiore (ad esempio 3 giorni) per assicurarti che le lapidi generate a causa dell'eliminazione dei token vengano eliminate più rapidamente dal datastore.

Per approfondire

• Framework OAuth 2.0
• Proteggere le API con OAuth
• Limiti di prodotto di Edge