Analiza powypadkowa: awarie uwierzytelniania spowodowane przez cache JWKS i rotację klucza podpisującego

Data: 8 stycznia 2026 r. (PST)

Czas trwania: około 60 minut

Wpływ: niektórzy użytkownicy produkcyjni napotkali problemy z logowaniem i walidacją tokenów; logowanie do Konsoli mogło być utrudnione

Podsumowanie#

Niezgodność między obrotowanym kluczem podpisującym a zapamiętanym (w cache) JWKS w naszej domenie *.logto.io spowodowała błędy walidacji tokenów. Wyczyściliśmy cache JWKS i przywróciliśmy poprzedni klucz podpisujący, aby przywrócić usługę.

Niektórzy użytkownicy mogą nadal doświadczać problemów z logowaniem do Konsoli z powodu pamięci podręcznej przeglądarki. Przepraszamy za powstałe niedogodności.

Oś czasu (PST)#

• 16:00 rozpoczęcie incydentu (wzrost liczby błędów walidacji uwierzytelniania/tokenów)
• 16:35 zidentyfikowano przyczynę (JWKS zapamiętany w pamięci podręcznej podczas rotacji klucza podpisującego)
• 16:41 wyczyszczono cache
• 16:49 przywrócono poprzedni klucz podpisujący
• 17:00 usługa odzyskana; dalsze monitorowanie

Szczegóły incydentu#

Wpływ#

W trakcie trwania incydentu niektórzy użytkownicy nie mogli się zalogować, a także pojawiły się błędy podczas walidacji tokenów. Dotknęło to wielu środowisk produkcyjnych i mogło także zablokować dostęp do Konsoli Logto.

Nie znaleźliśmy dowodów na nieautoryzowany dostęp związany z tym incydentem; wpływ był ograniczony wyłącznie do błędów uwierzytelniania.

Działania dla klientów#

Jeśli wciąż nie możesz zalogować się do Konsoli Logto, spróbuj:

• otworzyć okno incognito/prywatne, lub
• wyczyścić/wyłączyć pamięć podręczną przeglądarki, a następnie spróbować ponownie

Co się stało#

1. Zaktualizowaliśmy ustawienia cache JWKS dla domen klientów (*.logto.app). Cache JWKS był błędnie nadal aktywny w naszej domenie Cloud (*.logto.io).
2. Przeprowadziliśmy rotację klucza podpisującego dla naszej usługi Cloud. Ponieważ odpowiedzi JWKS dla *.logto.io były zapamiętane w cache, niektórzy klienci wciąż używali nieaktualnych kluczy JWKS i nie mogli zweryfikować nowych tokenów.
3. Wyczyściliśmy cache JWKS dla *.logto.io, przywróciliśmy poprzedni klucz podpisujący, a następnie ponownie wyczyściliśmy cache JWKS, by upewnić się, że klienci używają przywróconego zestawu kluczy.
4. Uwierzytelnianie zostało przywrócone. Niektórzy użytkownicy mogą nadal napotykać problemy z logowaniem do Konsoli z powodu cache przeglądarki.

Wnioski#

Rotacja kluczy to nie tylko zadanie związane z zarządzaniem kluczami. To zmiana end-to-end, która musi uwzględniać zachowanie cache pomiędzy wystawcami a weryfikatorami. Rozbieżności konfiguracji pomiędzy domenami (*.logto.app vs *.logto.io) stanowią realne ryzyko. Zmiany bezpieczne dla jednej domeny mogą spowodować błędy w innej, jeśli nie zostaną zastosowane konsekwentnie.

Nasze dotychczasowe testy integracyjne nie obejmowały zachowania cache JWKS typowego dla produkcji, dlatego ten scenariusz awarii nie został przetestowany przed rotacją.

Działania zapobiegawcze#

Wdrażamy:

• Wymuszone unieważnianie cache JWKS jako obowiązkowy krok przed rotacją klucza podpisującego (rotacja dopiero po zakończeniu unieważniania cache)
• Utrzymywanie wyłączonego cache’owania JWKS aż do wdrożenia unieważniania, następnie ponowne włączenie cache dla wydajności
• Testy integracyjne odwzorowujące środowisko produkcyjne dla rotacji kluczy, uwzględniające zachowanie cache JWKS i sprawdzenia unieważniania cache