Logto v1.43.0 rozszerza możliwości łączenia aplikacji i korporacyjnych dostawców tożsamości, jednocześnie wzmacniając granice bezpieczeństwa wokół tokenów oraz zapytań wychodzących. Wersja ta wprowadza dynamiczne aplikacje z dokumentami metadanych OAuth Client ID, podpisane żądania uwierzytelniania SAML oraz ujednolicony runtime dla Custom JWT i Actions. Aktualizacja dodatkowo wzmacnia wymianę tokenów, webhooki oraz korporacyjne SSO, a także ulepsza Centrum Konta, dodaje wsparcie dla języka hiszpańskiego (Meksyk) i zwiększa niezawodność. Oto co nowego.
Interfejs logowania obsługuje teraz es-MX (hiszpański, Meksyk).
Dla użytkowników, których językiem jest hiszpański (Meksyk), domyślny kod kraju dla numerów telefonu to Meksyk (+52). Wersja ta naprawia również znaczniki list formatter oraz ostatnią nieprzetłumaczoną wiadomość MFA w lokalizacjach hiszpańskich.
Zapytania wychodzące skonfigurowane przez Management API są teraz blokowane, gdy rozwiązują się do adresów loopback, prywatnych, link-local, metadanych chmurowych lub innych adresów o specjalnym przeznaczeniu.
Ochrona obejmuje teraz:
Dostarczanie webhooków, w tym POST /api/hooks/:id/test.
Discovery, tokeny i żądania userinfo OIDC enterprise SSO.
Pobieranie metadanych dostawcy tożsamości SAML.
Każdy przekierowywany krok tych żądań.
Nazwy DNS są weryfikowane przy ustanawianiu połączenia, więc host, który rozwiązuje się na chroniony adres, zostaje odrzucony tak samo jak dosłowny adres IP.
Oprócz wymagania tokenów pierwszostronnych jako subject, Logto teraz weryfikuje, czy JWT przedstawiony jako subject access_token jest faktycznie tokenem dostępu.
JWT musi zawierać:
Nagłówek typu RFC 9068 at+jwt.
Żądanie client_id.
Tokeny ID OIDC oraz inne JWT podpisane przez tenant nie mogą już być użyte zamiast tokenu dostępu. Nieprawidłowe tokeny subject są odrzucane z invalid_grant.
Aplikacje trzecie nie mogą już modyfikować danych konta przez Account API lub Verification API. Takie żądania teraz zwracają:
Aplikacje pierwszostronne, w tym Centrum Konta i Konsola, nie są objęte tym ograniczeniem.
Sprawdzenie kończy się blokadą dla nieznanych identyfikatorów klienta. Dotyczy to m.in. usuniętych aplikacji, których tokeny są nadal aktywne oraz klientów CIMD, których identyfikator to URL metadanych.
Żadna trasa odczytu nie otrzymała nowej bezpośredniej ochrony. Jednak następujące odczyty wymagają rekordów weryfikacji utworzonych przez chronione trasy i są więc już nieosiągalne dla aplikacji trzecich:
GET /api/my-account/grants
GET /api/my-account/sessions
GET /api/my-account/mfa-verifications/backup-codes
Zawieszeni użytkownicy nie otrzymują nowych tokenów#
Wydawanie tokenów i userinfo odrzuca teraz zawieszonych użytkowników z invalid_grant, zgodnie z dotychczasowym zachowaniem w przypadku usuniętych użytkowników.
Dotyczy to wszystkich przepływów: refresh token, authorization code, device code i wymiany tokenów, nawet jeśli wcześniejsze unieważnienie tokena lub sesji nie zostało zakończone.
Uprawnienia aplikacji trzecich są ponownie weryfikowane#
Usunięcie zakresu użytkownika z konfiguracji zgody aplikacji trzeciej wpływa teraz na istniejące zgody oraz nowe żądania autoryzacji.
Wymiana tokenów odświeżania usuwa zakresy, które nie są już skonfigurowane.
Żądania autoryzacji wznawiające istniejącą zgodę kończą się błędem invalid_scope w odpowiedniej sytuacji.
Żądania tokenu organizacji kończą się insufficient_scope po usunięciu zakresu organizations.
Przesłanie zgody nie przyznaje już zakresu, który został usunięty podczas otwartej ekranu zgody.
Licznik blokad Sentinel używa teraz tej samej znormalizowanej formy identyfikatora co wyszukiwanie konta:
Adresy e-mail są zapisywane małymi literami.
Numery telefonów są kanonizowane.
Nazwy użytkowników są porównywane bez uwzględnienia wielkości liter, jeśli taka jest polityka tenantów.
Zapobiega to tworzeniu oddzielnych liczników prób dla różnych zapisów tego samego identyfikatora i osłabianiu maxAttempts.
Ręczne odblokowanie czyści także odpowiedniki pisowni, jeśli dotyczą tego samego konta. Po aktualizacji istniejąca blokada zapisana pod niekanoniczną pisownią może zakończyć się wcześniej, ale żaden użytkownik nie zostanie bardziej zablokowany niż przedtem.
Cofnięcie uprawnień aplikacji trzeciej użytkownika unieważnia teraz wyłącznie tokeny tej aplikacji. Sesja SSO w przeglądarce użytkownika pozostaje aktywna.
Klucze podpisujące eliptyczne krzywe teraz deklarują algorytm zgodny z krzywą: P-256 używa ES256, P-384 używa ES384, a P-521 używa ES512.
Przejście z logowania passkey na logowanie kodem weryfikacyjnym nie blokuje już możliwości ukończenia CAPTCHA przez użytkownika.
Wiadomości OIDC invalid_scope i insufficient_scope pokazują teraz odrzucony zakres zamiast surowych miejsc oznaczonych jako {{error_description}} lub {{scope}}.
Safari i inne menedżery haseł mogą teraz sugerować i zapisywać silne hasło na ekranach ustawiania oraz resetowania hasła, używając poprawnego identyfikatora konta.
Wartości quality w Accept-Language z białymi znakami, jak en; q=0.7, są teraz poprawnie analizowane. Nieprawidłowe wartości quality są bezpiecznie pomijane, zamiast skutkować NaN.
Mechanizm allowlist/denylist Gmaila traktuje teraz gmail.com i googlemail.com jako równoważne i ignoruje kropki w części lokalnej adresu.
Konsola zawiera teraz jaśniejsze przykłady, opisy oraz krótsze podpowiedzi dla niestandardowych reguł e-mail.
Zapis ustawień Centrum Konta lub rejestracji usuwa teraz odniesienia do usuniętych niestandardowych pól profilu, zamiast zwracać custom_profile_fields.entity_not_exists_with_names.
Usunięte pola nadal można usuwać z Konsoli, nawet gdy kontrola uprawnień jest wyłączona.
Endpoints Management API do relacji przyjmują teraz puste tablice scope lub roli jako operacje no-op zamiast zwracać błąd 500. Dotyczy to endpointów takich jak:
POST /applications/:applicationId/user-consent-scopes
POST /organizations/:id/users/:userId/roles
Walidacja daty obejmuje teraz cały wprowadzony ciąg i odrzuca znaki po poprawnej dacie.
Konektor Microsoft Azure AD obsługuje teraz opcję disableEmailSync.
Domyślnie konektor nadal kopiuje atrybut Microsoft Graph mail do profilu użytkownika Logto. Włącz tę opcję, aby konektor uwierzytelniał użytkownika bez synchronizowania tego adresu, zgodnie z istniejącą kontrolą dla Azure OIDC enterprise SSO.
Działania wymagane — ochrona zapytań wychodzących: Jeśli webhooki lub konektory enterprise SSO mają celowo dostęp do usług w sieci prywatnej, przed aktualizacją dodaj wymagane adresy IP lub zakresy CIDR do SSRF_ALLOWED_ADDRESSES:
Listowanie tylko wymaganych miejsc docelowych jest bezpieczniejsze niż wyłączenie ochrony globalnie.
Kompatybilność aplikacji dynamicznych: Skonfigurowanie SSRF_ALLOWED_ADDRESSES wyłącza CIMD, więc nieautoryzowani dynamiczni klienci nie mogą wykorzystać allowlisty do dostępu do prywatnych usług. Ustawienie SSRF_PROTECTION_DISABLED=true również wyłącza CIMD.
Kompatybilność konfiguracji: OIDC_PROVIDER_SSRF_PROTECTION_DISABLED nadal jest obsługiwane jako alias dla SSRF_PROTECTION_DISABLED. Te zmienne mają zastosowanie tylko do wdrożeń typu self-hosted.
Limity runtime skryptów: Skrypty Custom JWT i Actions muszą zakończyć się w ciągu 5 sekund, pozostać w limicie 128 MB pamięci oraz zwracać wartości serializowalne do JSON.
Wymagana migracja bazy danych: Wersja ta zawiera nowe zmiany schematu i indeksów. Po aktualizacji uruchom polecenie zmiany schematu bazy danych (npm run alteration deploy w obrazie @logto/cli/core lub logto db alteration deploy) przed uruchomieniem nowej wersji. Sprawdź przewodnik aktualizacji.
