Antywzór: nie ustawiaj czasu ważności tokenów OAuth

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Apigee Edge udostępnia platformę OAuth 2.0 do zabezpieczania interfejsów API. OAuth2 to jeden z najpopularniejszych otwartych systemów uwierzytelniania i autoryzacji opartych na tokenach. Umożliwia aplikacjom klienckim dostęp do interfejsów API w imieniu użytkowników bez konieczności ujawniania nazwy użytkownika i hasła.

Apigee Edge umożliwia programistom generowanie tokenów dostępu lub odświeżanie przez wdrożenie dowolnego z 4 typów uwierzytelniania OAuth2 – danych logowania klienta, hasła, tajnego i kodu autoryzacji – przy użyciu zasady OAuthv2. Aplikacje klienckie używają tokenów dostępu do korzystania z bezpiecznych interfejsów API. Każdy token dostępu ma własny czas ważności, który można ustawić w zasadach OAuthv2.

Tokeny odświeżania są wystawiane opcjonalnie wraz z tokenami dostępu z niektórymi typami uwierzytelniania. Tokeny odświeżania służą do uzyskiwania nowych, ważnych tokenów dostępu po wygaśnięciu lub unieważnieniu pierwotnego tokena dostępu. Czas ważności tokenów odświeżania można też ustawić w zasadzie OAuthv2.

Ten antywzorzec jest powiązany z antywzorcem polegającym na ustawianiu długiego okresu ważności tokenów OAuth.

Antywzór

Ustawienie czasu ważności tokena odświeżania w zasadzie OAuthv2 prowadzi do nagromadzenia tokenów OAuth i zwiększenia wykorzystania miejsca na dysku w węzłach Cassandra.

Poniższa przykładowa zasada OAuthV2 wskazuje brakującą konfigurację dla <RefreshTokenExpiresIn>: 

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

W tym przykładzie:

  • Token dostępu ma dostatecznie krótki czas ważności, który wynosi 30 minut.
  • Nie ustawiono daty ważności tokena odświeżania.
  • Token odświeżania pozostaje bezterminowo w magazynie danych (Cassandra), co powoduje kumulację danych.
  • Token odświeżania wygenerowany bez daty ważności może być używany do generowania tokenów dostępu w nieskończoność.
  • Jeśli ruch do tego interfejsu API wynosi 10 żądań na sekundę, może on wygenerować nawet 864 tys. tokenów dziennie.

Wpływ

  • Jeśli token odświeżania zostanie utworzony bez daty ważności, ma 2 główne konsekwencje:
    • Token odświeżania można wykorzystać w dowolnej chwili w przyszłości, a nawet w wielu latach, aby uzyskać token dostępu. Może to mieć wpływ na bezpieczeństwo.
    • Wiersz w Cassandra zawierający token odświeżania nigdy nie zostanie usunięty. Spowoduje to gromadzenie się danych w systemie Cassandra.
  • Jeśli nie użyjesz tokena odświeżania w celu uzyskania nowego tokena dostępu, ale utworzysz nowy token odświeżania i token dostępu, starszy token odświeżania pozostanie w usłudze Cassandra. W związku z tym tokeny odświeżania będą nadal gromadzić tokeny w Cassandra, co będzie dodatkowo powodować wzmożony ruch, większe wykorzystanie dysku i kompresowanie, a w końcu będą powodować opóźnienia odczytu i zapisu w systemie Cassandra.

Sprawdzona metoda

Używaj odpowiednio krótkiego okresu ważności zarówno dla tokenów odświeżania, jak i tokenów dostępu. Zapoznaj się ze sprawdzonymi metodami dotyczącymi ustawiania okresów ważności tokenów odświeżania i tokenów dostępu. Pamiętaj, aby określić w zasadzie konfigurację wygaśnięcia zarówno dla dostępu, jak i tokena odświeżania. Więcej informacji o konfiguracji zasad znajdziesz w dokumentacji zasad OauthV2.

Sprawdzone metody dotyczące Edge dla klientów Private Cloud

Ta sekcja zawiera sprawdzone metody dotyczące Edge dla klientów Private Cloud.

Określ domyślną datę wygaśnięcia tokena odświeżania

Domyślnie, jeśli data ważności tokena odświeżania nie jest określona w konfiguracji zasad, Edge tworzy token odświeżania bez terminu wygaśnięcia. Możesz zastąpić to działanie, wykonując te czynności:

  1. W węźle procesora wiadomości edytuj lub utwórz plik zastąpienia konfiguracji $APIGEE_ROOT/customer/application/message-processor.properties. Upewnij się, że użytkownik apigee może odczytać ten plik.
  2. Dodaj do pliku ten wiersz: 
    conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000
    Spowoduje to ustawienie domyślnej daty ważności tokena odświeżania (o ile nie jest to określone w zasadzie) na 1 godzinę. Możesz zmienić tę wartość domyślną w zależności od potrzeb biznesowych.
  3. Ponownie uruchom usługę procesora wiadomości: 
    apigee-service edge-message-processor restart
  4. Powtórz powyższe kroki jeden po drugim we wszystkich węzłach procesora wiadomości.

Sprawdzone metody w Cassandrze

Spróbuj uaktualnić Apigee do najnowszej dostępnej publicznie wersji. Apigee wciąż publikuje poprawki i ulepszenia, które ulepszają i optymalizują zarządzanie tokenami w Apigee. W Apigee tokeny dostępu i odświeżania są przechowywane w Cassandra w przestrzeni kluczy „kms”. Upewnij się, że strategia kompresowania tej przestrzeni kluczy jest ustawiona na LeveledCompactionStrategy. Sprawdź, czy nie występują te indeksy:
  • kms.oauth_20_access_tokens.oauth_20_access_tokens_organization_name_idx#f0f0f0 oraz
  • kms.oauth_20_access_tokens.oauth_20_access_tokens_status_idx

Możesz też zmniejszyć wartość gc_grace_seconds w tabeli kms.oauth_20_access_tokens z domyślnego 10 do niższej wartości (np. 3 dni), aby mieć pewność, że nagrobki wygenerowane w wyniku usuwania tokenów zostaną szybciej usunięte z magazynu danych.

Więcej informacji