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:
- 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 denapigee
-Nutzer lesbar ist. - 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. - Starten Sie den Nachrichtenprozessor-Dienst neu:
apigee-service edge-message-processor restart
- 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 aufLeveledCompactionStrategy
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.