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

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation.
Weitere Informationen

Apigee Edge bietet das OAuth 2.0-Framework für sichere 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 eines der die vier OAuth2-Zustimmungstypen an: Clientanmeldedaten password, Implicit und Autorisierungscode – mithilfe der OAuthv2-Richtlinie. Clientanwendungen verwenden Zugriffstoken, um sichere APIs zu nutzen. Jedes Zugriffstoken hat einen eigenen Ablauf die in den OAuthv2-Richtlinien 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 ist mit dem Anti-Pattern von Festlegen einer langen Ablaufzeit für OAuth-Tokens

Anti-Pattern

Keine Ablaufzeit für ein Aktualisierungstoken in der OAuthv2-Richtlinie festlegen führt zu einer Anhäufung von OAuth-Tokens und erhöhter Speicherplatznutzung auf Cassandra-Knoten.

Im folgenden Beispiel für eine OAuthV2-Richtlinie wird eine fehlende 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 hat eine relativ geringe Ablaufzeit von 30 Minuten.
  • Die Ablaufzeit des Aktualisierungstokens ist nicht festgelegt.
  • Das Aktualisierungstoken bleibt dauerhaft im Datenspeicher (Cassandra) erhalten, sodass Daten Akkumulation.
  • Ein ohne Ablaufzeit erstelltes Aktualisierungstoken kann unbegrenzt zum Generieren von Zugriffstokens verwendet werden.
  • Wenn der Traffic zu dieser API zehn Anfragen pro Sekunde beträgt, können bis zu 864.000 Tokens generiert werden an einem Tag.

Auswirkungen

  • Wird das Aktualisierungstoken ohne Ablauf erstellt, hat dies zwei wesentliche Konsequenzen: <ph type="x-smartling-placeholder">
      </ph>
    • Ein Aktualisierungstoken kann jederzeit in Zukunft, möglicherweise über Jahre, verwendet werden, um einen Zugriff zu erhalten Token. 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, und erstellen stattdessen ein neues Aktualisierungs- und Zugriffstoken. Das ältere Aktualisierungstoken verbleibt in Cassandra. Aktualisieren Sie deshalb „Cassandra“ sammelt sich immer mehr Tokens, erhöhte Laufwerksnutzung und stärkere Verdichtungen, was letztendlich zu Lese-/Schreibvorgängen und Latenzen in Cassandra.

Best Practice

Verwenden Sie eine entsprechend niedrige Ablaufzeit sowohl für Aktualisierungs- als auch für Zugriffstokens. Weitere Informationen finden Sie unter Best Practice zum Festlegen des Ablaufdatums Aktualisierungs- und Zugriffstokens. Sie müssen für beide Zugriffsrechte eine Ablaufkonfiguration angeben und aktualisieren Sie das Token in der Richtlinie. Weitere Informationen finden Sie im OauthV2-Richtliniendokumentation finden Sie weitere Informationen zur Richtlinienkonfiguration.

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

Der Abschnitt beschreibt Best Practices speziell für Edge für Private Cloud-Kunden.

Standardablauf des Aktualisierungstokens angeben

Wenn in einer Richtlinienkonfiguration standardmäßig keine Ablaufzeit eines Aktualisierungstokens angegeben ist, Edge erstellt ein Aktualisierungstoken ohne Ablauf. Sie können dieses Verhalten überschreiben, gehen Sie so vor:

  1. Bearbeiten oder erstellen Sie die Konfigurationsüberschreibungsdatei auf einem Nachrichtenprozessorknoten $APIGEE_ROOT/customer/application/message-processor.properties Diese Datei muss apigee-Nutzer lesbar ist.
  2. Fügen Sie der Datei die folgende Zeile hinzu:
    conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000
    Wenn in einer Richtlinie kein Aktualisierungstoken angegeben ist, wird der standardmäßige Ablauf des Aktualisierungstokens auf 1 Stunde festgelegt. Sie können diesen Standardwert Ihren geschäftlichen Anforderungen entsprechend ändern.
  3. Starten Sie den Nachrichtenverarbeitungsdienst neu:
    apigee-service edge-message-processor restart
  4. Wiederholen Sie die obigen Schritte nacheinander in allen Message Processor-Knoten.

Best Practices in Cassandra

Führen Sie ein Upgrade auf die neueste öffentlich verfügbare Version von Apigee durch. Apigee geht weiter um Fehlerkorrekturen und Verbesserungen zu veröffentlichen, die die Verwaltung von Tokens in Apigee. In Apigee werden Zugriffs- und Aktualisierungstoken in Cassandra gespeichert. im Schlüsselraum „kms“. Sie sollten darauf achten, dass die Verdichtungsstrategie Der Keyspace ist auf LeveledCompactionStrategy gesetzt. Achten Sie darauf, dass die folgenden Indexe nicht vorhanden sind: <ph type="x-smartling-placeholder">
    </ph>
  • 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 in einen (z. B. 3 Tage), um sicherzustellen, dass Tombstones, die aufgrund gelöschter Tokens generiert wurden, automatisch schneller aus dem Datenspeicher gelöscht werden.

Weitere Informationen