Analiza post mortem: nieoczekiwana zmiana JWT `iss`

Podsumowanie#

Dnia 2024-03-18 aktualizacja zmieniająca zachowanie wydawcy JWT w Logto Cloud zakłóciła przepływy autoryzacji dla użytkowników z niestandardowymi domenami i walidacją iss. Naprawa wymagała, aby ci użytkownicy zaktualizowali swoją logikę walidacji.

• Dotknięci użytkownicy: użytkownicy z włączonymi niestandardowymi domenami i przeprowadzający walidację iss.
• Powaga: krytyczna, uniemożliwiająca walidację iss w przepływach autoryzacji.

Przyczyna źródłowa#

Aktualizacja zmieniła pole iss, by odpowiadało żądanemu lokalowi, psując istniejące walidacje oczekujące poprzedniego domyślnego wydawcy.

Chronologia#

• 2024-03-18 10:00 (UTC): wdrożono aktualizacje, zmieniające zachowanie iss.
• 2024-03-18 23:30 (UTC): otrzymano pierwsze zgłoszenie od użytkownika o problemie ze starym zachowaniem.
• 2024-03-19 12:00 (UTC): potwierdzono problem i rozpoczęto dochodzenie.
• 2024-03-19 14:00 (UTC): zidentyfikowano przyczynę źródłową i wpływ.
• 2024-03-20 20:00 (UTC): przygotowano e-mail do dotkniętych użytkowników.
• 2024-03-20 06:00 (UTC): wysłano e-maile do wszystkich dotkniętych użytkowników.

Analiza wpływu#

Szczegóły wydania#

Logto Cloud wspiera niestandardowe domeny dla autoryzacji, deweloperzy mający włączone tenenty z niestandardowymi domenami mogą ustawić endpoint na niestandardową domenę w SDK, a końcowy użytkownik użyje tego endpointu do inicjalizacji procesu autoryzacji i uzyskania tokenów. Niektóre tokeny mają formę JWT, która zawiera pole iss wskazujące wydawcę tego tokenu. Wcześniej, nawet gdy używano niestandardowego endpointu domeny do żądania tokenu dostępu, wydawca nadal domyślnie ustawiał się na naszą standardową domenę ([tenant-id].logto.app).

Jednak domena wydawcy powinna być taka sama jak żądany endpoint. Dlatego opublikowaliśmy aktualizację, aby naprawić ten problem, i teraz pole iss automatycznie będzie odzwierciedlać domenę używaną w żądaniu.

Dla tych, którzy już używali niestandardowej domeny do przyznawania tokenów i zaimplementowali walidację pola iss na serwerze zasobów, to mogła okazać się zmiana łamiąca. Istniejąca kontrola autoryzacyjna będzie się nie powodzić z powodu zmiany wydawcy. Aby to naprawić, deweloperzy muszą zmienić kod walidacji, zastąpić oczekiwanego wydawcę na nowego z niestandardową domeną.

Nie udało nam się w pełni rozważyć wpływu na istniejące walidacje iss, w rezultacie to wydanie stało się zmianą łamiącą bez wcześniejszego powiadomienia.

Rozwiązanie#

Powiadomiliśmy dotkniętych użytkowników za pomocą e-maili, doradzając im, aby zaktualizowali swoje walidacje iss, aby dopasować się do żądanego lokalizacji.

Wycofania?#

Zmiana jest konieczną poprawką pola wydawcy, a niektórzy użytkownicy mogą już się dostosować do nowego zachowania. Wycofanie spowodowałoby zamieszanie i niespójność.

Wyciągnięte wnioski#

• Zmiany w kodzie wpływające na podstawową autoryzację muszą być zatwierdzane przez zespół oprócz regularnych przeglądów.
• Testy automatyczne powinny obejmować więcej przypadków, zwłaszcza w specyficznych dla chmury scenariuszach.

Środki zapobiegawcze i naprawcze#

• Dodaj testy integracyjne: Dodaj przypadki testowe obejmujące scenariusz przedstawiony w tym incydencie.
• Projekty monitorowania funkcji: Oprócz Logto Cloud, utwórz nasze własne, poboczne projekty i głęboko zintegrowane z Logto, aby uchwycić potencjalne problemy przed wydaniami.