Anti-Pattern: Keine Ablaufzeit für OAuth-Tokens festlegen

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation
weitere Informationen

Apigee Edge bietet das OAuth 2.0-Framework zum Schutz von APIs. OAuth2 ist eines der gängigsten offenen, tokenbasierten Authentifizierungs- und Autorisierungsschemen. Damit können Client-Anwendungen im Namen von Nutzern auf APIs zugreifen, ohne dass die Nutzer Nutzernamen und Passwort preisgeben müssen.

Mit Apigee Edge können Entwickler Zugriffs- und/oder Aktualisierungstokens generieren, indem sie mithilfe der OAuthv2-Richtlinie einen der vier OAuth2-Zustimmungstypen – Clientanmeldedaten, Passwort, implizit und Autorisierungscode – implementieren. Clientanwendungen verwenden Zugriffstoken, um sichere APIs zu nutzen. Jedes Zugriffstoken hat eine eigene Ablaufzeit, die in der OAuthv2-Richtlinie festgelegt werden kann.

Aktualisierungstoken werden optional mit einigen Grant-Typen zusammen mit Zugriffstoken ausgegeben. Mit Aktualisierungstoken werden neue, gültige Zugriffstoken abgerufen, nachdem das ursprüngliche Zugriffstoken abgelaufen oder widerrufen wurde. Die Ablaufzeit für Aktualisierungstokens kann auch in der OAuthv2-Richtlinie festgelegt werden.

Dieses Anti-Pattern bezieht sich auf das Anti-Pattern, das das Festlegen einer langen Ablaufzeit für OAuth-Tokens darstellt.

Anti-Pattern

Wenn in der OAuthv2-Richtlinie keine Ablaufzeit für ein Aktualisierungstoken festgelegt wird, sammeln sich OAuth-Tokens an und erhöht den Speicherplatz auf den Cassandra-Knoten.

Im folgenden Beispiel für eine OAuthV2-Richtlinie wird eine fehlende Konfiguration für <RefreshTokenExpiresIn> dargestellt:

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

Im obigen Beispiel gilt Folgendes:

  • Das Zugriffstoken hat eine relativ geringe Ablaufzeit von 30 Minuten.
  • Für das Aktualisierungstoken ist keine Ablaufzeit festgelegt.
  • Das Aktualisierungstoken bleibt im Datenspeicher (Cassandra) dauerhaft bestehen, wodurch Daten angesammelt werden.
  • Ein Aktualisierungstoken, das ohne Ablauf erstellt wurde, kann unbegrenzt zum Generieren von Zugriffstokens verwendet werden.
  • Wenn der Traffic zu dieser API 10 Anfragen pro Sekunde beträgt, können bis zu 864.000 Tokens pro Tag generiert werden.

Auswirkungen

  • Wenn das Aktualisierungstoken ohne Ablauf erstellt wird, hat dies zwei wesentliche Konsequenzen:
    • Das Aktualisierungstoken kann jederzeit verwendet werden, möglicherweise sogar Jahre, um ein Zugriffstoken zu erhalten. Dies kann Auswirkungen auf die Sicherheit haben.
    • Die Zeile in Cassandra, die das Aktualisierungstoken enthält, wird niemals gelöscht. Dadurch sammeln sich Daten in Cassandra an.
  • Wenn Sie das Aktualisierungstoken nicht verwenden, um ein neues Zugriffstoken zu erhalten, sondern stattdessen ein neues Aktualisierungs- und Zugriffstoken erstellen, verbleibt das ältere Aktualisierungstoken in Cassandra. Infolgedessen sammeln sich weiterhin Aktualisierungstokens in Cassandra an, was zu Bloat, erhöhter Laufwerksnutzung und stärkerer Verdichtung führt und letztendlich zu Lese-/Schreiblatenzen in Cassandra führen.

Best Practices

Verwenden Sie eine entsprechend niedrige Ablaufzeit sowohl für Aktualisierungs- als auch für Zugriffstokens. Weitere Informationen zum Festlegen von Ablaufzeiten für Aktualisierungs- und Zugriffstokens finden Sie in den Best Practices. Geben Sie in der Richtlinie unbedingt eine Ablaufkonfiguration sowohl für das Zugriffs- als auch für das Aktualisierungstoken an. Weitere Informationen zur Richtlinienkonfiguration finden Sie in der Dokumentation zur OauthV2-Richtlinie.

Best Practices speziell für Edge for Private Cloud-Kunden

Im Abschnitt werden Best Practices speziell für Edge for Private Cloud-Kunden beschrieben.

Standardablaufzeit für Aktualisierungstokens angeben

Wenn in einer Richtlinienkonfiguration kein Aktualisierungstoken angegeben ist, erstellt Edge standardmäßig ein Aktualisierungstoken ohne Ablauf. Sie können dieses Verhalten mit der folgenden Vorgehensweise überschreiben:

  1. Bearbeiten oder erstellen Sie auf einem Message Processor-Knoten die Konfigurationsüberschreibungsdatei $APIGEE_ROOT/customer/application/message-processor.properties. Achten Sie darauf, dass diese Datei für den apigee-Nutzer lesbar ist.
  2. Fügen Sie der Datei die folgende Zeile hinzu:
    conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000
    Dadurch wird die Standardablaufzeit für Aktualisierungstokens auf 1 Stunde festgelegt, wenn in einer Richtlinie kein Token angegeben ist. Sie können diesen Standardwert entsprechend Ihren Geschäftsanforderungen ändern.
  3. Starten Sie den Nachrichtenprozessor-Dienst neu:
    apigee-service edge-message-processor restart
  4. Wiederholen Sie die oben genannten Schritte nacheinander in allen Message Processor-Knoten.

Best Practices in Cassandra

Versuchen Sie, ein Upgrade auf die neueste öffentlich verfügbare Apigee-Version durchzuführen. Apigee veröffentlicht fortlaufend Fehlerkorrekturen und Verbesserungen, mit denen die Verwaltung von Tokens in Apigee verbessert und optimiert wird. In Apigee werden Zugriffs- und Aktualisierungstokens in Cassandra im Schlüsselbereich "kms" gespeichert. Die Komprimierungsstrategie dieses Schlüsselbereichs muss auf LeveledCompactionStrategy festgelegt sein. Überprüfen Sie, ob die folgenden Indizes nicht vorhanden sind:
  • kms.oauth_20_access_tokens.oauth_20_access_tokens_organization_name_idx#f0f0f0 und
  • kms.oauth_20_access_tokens.oauth_20_access_tokens_status_idx

Sie können gc_grace_seconds in der Tabelle kms.oauth_20_access_tokens auch von der Standardeinstellung von 10 Tagen auf einen niedrigeren Wert (z. B. 3 Tage) reduzieren, damit Tombstones, die aufgrund des Löschens von Tokens generiert wurden, schneller dauerhaft aus dem Datenspeicher gelöscht werden.

Weitere Informationen