Logto v1.42.0 wprowadza pliki do weryfikacji niestandardowych domen, listy dozwolonych adresów e-mail z wzorcami zawierającymi symbole wieloznaczne, magiczne linki do resetowania hasła, webhook Grant.LimitExceeded oraz odświeżenie warstwy protokołu z node-oidc-provider v9, Koa 3 i włączoną domyślnie ochroną SSRF.
SimengDeveloper
Przestań tracić tygodnie na uwierzytelnianie użytkowników
Uruchamiaj bezpieczne aplikacje szybciej z Logto. Zintegruj uwierzytelnianie użytkowników w kilka minut i skup się na swoim głównym produkcie.
Logto v1.42.0 to wydanie skoncentrowane na domenach i warstwie protokołów. Umożliwia zespołom potwierdzenie własności domeny bez konieczności uruchamiania kolejnego hosta, precyzyjniejsze kontrolowanie, które adresy e-mail mogą uzyskać dostęp do dzierżawy oraz bardziej płynny proces resetowania hasła dla użytkowników końcowych. Pod maską Logto przechodzi na node-oidc-provider v9 i Koa 3 oraz domyślnie włącza ochronę SSRF dla wychodzących żądań OIDC. Oto nowości.
Zewnętrzne usługi często weryfikują własność domeny, prosząc o udostępnienie małego pliku pod określoną ścieżką. Dotychczas oznaczało to konieczność uruchomienia oddzielnego hosta obok niestandardowej domeny Logto.
Teraz możesz dołączyć pliki weryfikacyjne do aktywnej niestandardowej domeny z poziomu Konsola > Ustawienia dzierżawy > Domeny. Każdy plik posiada:
Ścieżkę, która może być nazwą pliku na poziomie głównym z rozszerzeniem (np. /verify.txt) lub ścieżką pod /.well-known/.
Typ zawartości text/plain lub application/json. Zawartość JSON jest walidowana podczas zapisu.
Zawartość do 16 KB.
Możesz skonfigurować do 10 plików na domenę, a ścieżki muszą być unikalne. Logto serwuje dokładne żądania GET i HEAD z ustawionym typem zawartości i utwardzonymi nagłówkami odpowiedzi. Istniejące ścieżki Logto mają zawsze pierwszeństwo nad plikiem weryfikacyjnym pod tą samą ścieżką, więc błędnie skonfigurowany plik nigdy nie przysłoni rzeczywistego endpointu. Konsola jest dostępna we wszystkich obsługiwanych językach.
Ponieważ Logto nie ingeruje w zawartość plików, metoda ta działa dla każdego schematu weryfikacji dostawcy, bez konieczności odwzorowywania zachowania charakterystycznego dla danego dostawcy.
Zasady dostępu do e-mail: allowlist i wzorce wieloznaczne#
Polityka czarnej listy adresów e-mail rozrasta się do pełnego zestawu zasad dostępu do poczty, konfigurowanych w Konsola > Zabezpieczenia > Czarne listy e-mail.
Niestandardowa lista dozwolonych e-maili. Skonfiguruj listę dozwolonych adresów e-mail, domen lub wzorców wieloznacznych. Jeśli lista dozwolonych jest ustawiona, tylko pasujące adresy e-mail są akceptowane przy nowych rejestracjach i przy nadawaniu nowych adresów e-mail — zarówno podczas rejestracji, jak i aktualizacji e-maila konta.
Wzorce wieloznaczne. Lista dozwolonych oraz czarna lista akceptują wzorce wieloznacznych adresów i domen, takie jak foo*@example.com, *@example.com oraz @*.example.com, obok dokładnych adresów ([email protected]) i domen (@example.com).
Ostrzeżenia o konflikcie. Konsola ostrzega, gdy wpis z listy dozwolonych również pasuje do reguły blokowania, gdy wpis z allowlist używa znaku plus, a subadresowanie e-maili jest zablokowane, oraz gdy łączne zasady nie pozwolą na żaden nowy e-mail.
Logika dopasowywania i walidacji jest współdzielona przez pomocnicze funkcje z @logto/core-kit, dzięki czemu wszędzie tam, gdzie adres e-mail trafia do dzierżawy, obowiązują te same zasady.
Aplikacja Experience obsługuje teraz scenariusze resetowania hasła, które weryfikują magiczne linki z jednorazowym tokenem bezpośrednio z ekranu resetowania hasła, oprócz kodów weryfikacyjnych.
Gdy uprawnienia OIDC są usuwane, ponieważ aplikacja przekroczyła maksymalny dozwolony limit uprawnień, Logto wyzwala teraz zdarzenie webhooka Grant.LimitExceeded, które można wybrać w ustawieniach webhooków w Konsoli jak każde inne zdarzenie.
Payload raportuje userId, applicationId, revokedGrantIds, maxAllowedGrants oraz preRevocationActiveGrantCount. Wywołanie jest typu fire-and-forget: błędy są zapisywane jako wpisy audytu TriggerHook.Grant.LimitExceeded i nigdy nie blokują odpowiedzi uwierzytelnienia.
Dostawca OIDC zaktualizowany do node-oidc-provider v9#
Największa zmiana to poprawka bezpieczeństwa w odwoływaniu tokenów.
Odwołanie nieprzezroczystego tokena dostępu powoduje teraz także odwołanie każdego tokena pod tym samym uprawnieniem, w tym tokena odświeżania. W v8 token odświeżania pozostawał użyteczny po odwołaniu, umożliwiając dalsze uzyskiwanie nowych tokenów dostępowych.
Inne zmiany protokołu w v9:
Endpoint odwołania teraz odrzuca tokeny dostępu JWT z kodem unsupported_token_type, zamiast zwracać odpowiedź sukcesu bez faktycznego odwołania, jak w v8.
Endpoint metadanych serwera autoryzacji zgodny z RFC 8414 jest dostępny pod /oidc/.well-known/oauth-authorization-server.
Usunięto zbędny claim at_hash z tokenów ID wydawanych na endpointzie token.
Tokeny ID nie zawierają już opcjonalnego nagłówka typ: "JWT". OpenID Connect określa, że tokeny ID są JWT, i nie wymaga sprawdzania tego nagłówka przez klientów.
Wymagana akcja dla niestandardowej weryfikacji tokenów ID. Nie jest wymagana żadna akcja podczas używania oficjalnego SDK Logto. W przypadku własnej implementacji, zaktualizuj ją tak, aby tolerowała brak claimu at_hash oraz brak nagłówka typ: "JWT".
Logto działa teraz na Koa 3, aktywnie rozwijanej linii wydawniczej, która jako pierwsza otrzymuje poprawki bezpieczeństwa Koa. Nie oczekuje się zmian w zachowaniu: wszystkie endpointy, przepływy OIDC i odpowiedzi API działają tak jak wcześniej.
Wewnętrzne sekrety aplikacji nie są już ujawniane przez Management API.
Polityka czarnej listy e-mail nie jest już zwracana w publicznych odpowiedziach procesu logowania.
Pobieranie przechowywanych access tokenów dostawców zewnętrznych przez Account API wymaga teraz zakresu uprawnień użytkownika identities, zgodnie z innymi endpointami social i enterprise SSO.
Kody weryfikacyjne API osób konta nie są już wysyłane na zablokowane adresy e-mail.
Walidacja adresów e-mail i domen sprawdza teraz kompletne wartości i wymusza bardziej rygorystyczne etykiety domen.
Poprawki doświadczenia, przechowywania i stabilności#
Gdy przepływ rejestracji social lub SSO zostaje odrzucony przez zasady dostępu do e-mail, potwierdzenie błędu zwraca teraz użytkownika na stronę logowania Logto zamiast wracać do zewnętrznego dostawcy tożsamości.
MFA jest teraz włączane automatycznie po powiązaniu czynnika przez Account API.
Tworzenie nowego konektora e-mail lub SMS odbywa się w pojedynczej transakcji bazodanowej (dodanie i usunięcie starych konektorów). Wcześniej awaria między tymi operacjami mogła zostawić duplikaty konektorów.
Dane uwierzytelniające klastra Redis są teraz dekodowane z procentów, więc połączenia są możliwe także przy znakach zarezerwowanych dla URL w loginie lub haśle.
TLS jest teraz prawidłowo włączany dla połączeń z klastrem Redis używających protokołu rediss.
jose v6: Konektory Apple, Google, OAuth i OIDC używają teraz jose 6, który opiera się na Web Crypto API zamiast modułu crypto Node. Podpisywanie tokenów i weryfikacja tokenów ID działają identycznie jak dotychczas.
GitLab: Usunięto nieużywaną zależność jose, więc instalacja konektora nie pobiera pakietu, z którego nie korzystał.
Aliyun SMS: Hongkońskie numery telefonów są teraz traktowane jako zagraniczne.
Aliyun SMS MAS: Podpis jest teraz wprowadzany jako dowolny tekst zamiast rozwijanego menu, więc działa nawet po ponownej rotacji podpisów przez Aliyun.
Dla użytkowników zarządzających własną infrastrukturą#
Wymagana akcja — ochrona SSRF dostawcy OIDC. Bezpieczeństwo wychodzących żądań zostało wzmocnione i ochrona SSRF jest teraz domyślnie włączona. Wdrożenia self-hosted, które muszą uzyskiwać dostęp do zaufanych endpointów relying-party w sieciach prywatnych, muszą ustawić OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true przed uruchomieniem Logto; w przeciwnym razie należy pozostawić tę zmienną nieustawioną.
Wymagana migracja bazy danych. To wydanie wprowadza zmiany schematu dla plików weryfikacji niestandardowych domen oraz wewnętrzne indeksy i tabele. Po aktualizacji uruchom polecenie alteracji bazy danych (npm run alteration deploy w obrazie @logto/cli/core lub logto db alteration deploy) przed uruchomieniem nowej wersji. Zobacz przewodnik aktualizacji po szczegóły.
Niestandardowa weryfikacja tokenów ID. Zobacz sekcję node-oidc-provider v9 powyżej w związku ze zmianami w at_hash i nagłówku typ.
