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

Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zu Apigee X. info

Apigee Edge stellt das OAuth 2.0-Framework zum Sichern von APIs bereit. 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 Aktualisierungs-Token generieren. Dazu müssen Sie einen der vier OAuth2-Grant-Typen – Client-Anmeldedaten, Passwort, Implizit und Autorisierungscode – mit der OAuthv2-Richtlinie implementieren. Clientanwendungen verwenden Zugriffstoken, um sichere APIs zu nutzen. Für jedes Zugriffstoken gilt ein eigenes Ablaufdatum, das in der OAuthv2-Richtlinie bestimmt 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 Aktualisierungstoken kann auch in der OAuthv2-Richtlinie festgelegt werden.

Dieses Anti-Pattern hängt mit dem Anti-Pattern zusammen, eine lange Ablaufzeit für OAuth-Tokens festzulegen.

Anti-Pattern

Wenn Sie in der OAuthv2-Richtlinie keine Ablaufzeit für ein Aktualisierungstoken festlegen, führt dies zu einer Akkumulation von OAuth-Token und zur erhöhten Nutzung des Speicherplatzes auf Cassandra-Knoten.

In der folgenden OAuthV2-Beispielrichtlinie fehlt die Konfiguration für <RefreshTokenExpiresIn>: 

<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:

  • Das Zugriffstoken ist auf eine eher geringe Ablaufzeit von 30 Minuten eingestellt.
  • Die Ablaufzeit des Aktualisierungstokens ist nicht festgelegt.
  • Das Aktualisierungstoken bleibt für immer im Datenspeicher (Cassandra) und führt zu einer Daten ansammlung.
  • Ein Aktualisierungstoken ohne Ablaufzeit kann unbegrenzt verwendet werden, um Zugriffstoken zu generieren.
  • Wenn der Traffic zu dieser API zehn Anfragen pro Sekunde beträgt, kann das bis zu 864.000 Token pro Tag generieren.

Auswirkungen

  • Wenn das Aktualisierungstoken ohne Ablaufzeit erstellt wird, hat das zwei Hauptfolgen:
    • Das Aktualisierungstoken kann jederzeit in der Zukunft, möglicherweise jahrelang, verwendet werden, um ein Zugriffstoken abzurufen. Dies kann Auswirkungen auf die Sicherheit haben.
    • Die Zeile in Cassandra, die das Aktualisierungstoken enthält, wird nie gelöscht. Dadurch sammeln sich Daten in Cassandra an.
  • Wenn Sie das Aktualisierungstoken nicht verwenden, um ein neues Zugriffstoken abzurufen, sondern ein neues Aktualisierungs- und Zugriffstoken erstellen, bleibt das ältere Aktualisierungstoken in Cassandra. Dadurch sammeln sich weiterhin Aktualisierungstoken in Cassandra an, was zu einer weiteren Aufblähung, erhöhter Festplattennutzung und stärkeren Komprimierungen führt und schließlich zu Latenzen beim Lesen und Schreiben in Cassandra führt.

Best Practice

Verwenden Sie eine angemessen kurze Ablaufzeit für Aktualisierungs- und Zugriffstoken. Siehe Best Practice zum Festlegen von Ablaufzeiten für Aktualisierungs- und Zugriffstoken Geben Sie in der Richtlinie eine Ablaufkonfiguration für Zugriffs- und Aktualisierungstoken an. Weitere Informationen zur Richtlinienkonfiguration finden Sie in der Dokumentation zur OauthV2-Richtlinie.

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

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

Standardablaufzeit für Aktualisierungstoken angeben

Wenn in einer Richtlinienkonfiguration keine Ablaufzeit für das Aktualisierungstoken angegeben ist, erstellt Edge standardmäßig ein Aktualisierungstoken ohne Ablaufzeit. 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. Prüfen Sie, ob die 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 das Aktualisierungstoken auf eine Stunde festgelegt, wenn in einer Richtlinie keine Ablaufzeit angegeben ist. Sie können diesen Standardwert entsprechend Ihren geschäftlichen Anforderungen ändern.
  3. Starten Sie den Message Processor-Dienst neu: 
    apigee-service edge-message-processor restart
  4. Wiederholen Sie die oben genannten Schritte einzeln auf allen Message Processor-Knoten.

Best Practices in Cassandra

Führen Sie ein Upgrade auf die neueste öffentlich verfügbare Version von Apigee durch. Apigee veröffentlicht weiterhin Fehlerkorrekturen und Verbesserungen, die die Verwaltung von Token in Apigee weiter verbessern und optimieren. In Apigee werden Zugriffs- und Aktualisierungstoken in Cassandra im Keyspace „kms“ gespeichert. Die Komprimierungsstrategie dieses Keyspace sollte auf LeveledCompactionStrategy festgelegt sein. Prü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 auch gc_grace_seconds in der Tabelle kms.oauth_20_access_tokens von den standardmäßigen 10 Tagen auf einen niedrigeren Wert (z. B. 3 Tage) reduzieren, damit Tombstones, die durch das Löschen von Token generiert werden, schneller aus dem Datenspeicher entfernt werden.

Weitere Informationen