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

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

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

Apigee Edge umożliwia deweloperom generowanie tokenów dostępu lub odświeżania przez wdrożenie dowolnego z 4 typów uwierzytelniania OAuth2 – dane uwierzytelniające klienta, hasło, uwierzytelnianie niejawne i kod autoryzacji – za pomocą 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 zasadzie OAuthv2.

W przypadku niektórych typów uwierzytelniania tokeny odświeżania są opcjonalnie wydawane razem z tokenami dostępu. Tokeny odświeżania służą do uzyskiwania nowych, ważnych tokenów dostępu po wygaśnięciu lub unieważnieniu oryginalnego tokena dostępu. Czas ważności tokenów odświeżania można też ustawić w zasadzie OAuthv2.

Ten antypattern jest powiązany z antypatternem ustawiania długiego czasu ważności tokenów OAuth.

Antypattern

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

W tym przykładzie zasady OAuthV2 brakuje konfiguracji <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 powyższym przykładzie:

  • Token dostępu ma ustawiony stosunkowo krótki czas ważności wynoszący 30 minut.
  • Czas ważności tokena odświeżania nie jest ustawiony.
  • Token odświeżania jest przechowywany w magazynie danych (Cassandra) na zawsze, co powoduje gromadzenie się danych
  • Token odświeżania wygenerowany bez czasu ważności może być używany bezterminowo do generowania tokenów dostępu.
  • 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 czasu ważności, wystąpią 2 główne konsekwencje:
    • Token odświeżania może być używany w dowolnym momencie w przyszłości, nawet przez wiele lat, do uzyskiwania tokena dostępu. Może to mieć wpływ na bezpieczeństwo.
    • Wiersz w systemie 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 do uzyskania nowego tokena dostępu, ale utworzysz nowy token odświeżania i token dostępu, starszy token odświeżania pozostanie w systemie Cassandra. W rezultacie tokeny odświeżania będą się nadal gromadzić w systemie Cassandra, co spowoduje dalsze zwiększenie rozmiaru danych, większe wykorzystanie dysku i częstsze kompresowanie, a w końcu spowoduje opóźnienia odczytu i zapisu w systemie Cassandra.

Sprawdzona metoda

Używaj odpowiednio krótkiego czasu ważności zarówno tokenów odświeżania, jak i tokenów dostępu. Zapoznaj się ze sprawdzoną metodą ustawiania czasu ważności tokenów odświeżania i tokenów dostępu. Upewnij się, że w zasadzie określono konfigurację czasu ważności zarówno tokena dostępu , jak i tokena odświeżania. Więcej informacji o konfiguracji zasad znajdziesz w dokumentacji zasady OauthV2.

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

W tej sekcji opisujemy sprawdzone metody dotyczące klientów Edge for Private Cloud.

Określanie domyślnego czasu ważności tokena odświeżania

Domyślnie, jeśli w konfiguracji zasady nie określono czasu ważności tokena odświeżania, Edge tworzy token odświeżania bez czasu ważności. 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 plik jest czytelny dla użytkownika apigee.
  2. Dodaj do tego pliku ten kod: 
    conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000
     Spowoduje to ustawienie domyślnego czasu ważności tokena odświeżania na 1 godzinę, jeśli w zasadzie nie określono innego czasu. Tę wartość domyślną możesz zmienić w zależności od potrzeb firmy.
  3. Ponownie uruchom usługę procesora wiadomości: 
    apigee-service edge-message-processor restart
  4. Powtórz powyższe kroki w każdym węźle procesora wiadomości.

Sprawdzone metody w systemie Cassandra

Spróbuj przejść na najnowszą wersję Apigee dostępną publicznie. Apigee continues stale udostępnia poprawki i ulepszenia, które poprawiają i optymalizują zarządzanie tokenami w Apigee. W Apigee tokeny dostępu i odświeżania są przechowywane w systemie Cassandra w przestrzeni kluczy „kms”. Upewnij się, że strategia kompresowania tej przestrzeni kluczy jest ustawiona na LeveledCompactionStrategy. Sprawdź, czy nie ma tych indeksów: nie
  • kms.oauth_20_access_tokens.oauth_20_access_tokens_organization_name_idx#f0f0f0 i
  • 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ślnych 10 dni do niższej wartości (np. 3 dni), aby mieć pewność, że znaczniki usunięcia wygenerowane w wyniku usunięcia tokenów zostaną szybciej usunięte z magazynu danych.

Więcej informacji