Aktualizacje produktu Logto (sierpień 2024)

Impersonacja użytkownika (RFC 8693: OAuth 2.0 Wymiana Tokenów)#

Dodano wsparcie dla impersonacji użytkownika przez Wymianę Tokenów:

• Nowy punkt końcowy Management API POST /subject-tokens, aby zażądać subject_token do wykorzystania w wymianie tokenów.
• Zaktualizowany punkt końcowy OIDC POST /oidc/token z nowym typem grant urn:ietf:params:oauth:grant-type:token-exchange, aby wymienić subject_token na impersonowany access_token użytkownika.

Zobacz Impersonacja użytkownika po więcej szczegółów.

Pole custom_data na poziomie aplikacji#

Dodano nowe pole obiektu arbitalnego custom_data do aplikacji. To pole może przechowywać dodatkowe informacje, których nie definiuje standardowy schemat Application.

Kliknij, aby rozszerzyć aktualizacje Management API

• Nowy punkt końcowy PATCH /api/applications/{applicationId}/custom-data, aby zaktualizować pole custom_data aplikacji.
• Aktualizacja punktu końcowego PATCH /api/applications/{applicationId}, aby umożliwić nadpisanie pola custom_data.

Kliknij, aby rozszerzyć aktualizacje Konsoli

Dodano nowy edytor danych JSON do strony szczegółowej aplikacji (z wyjątkiem aplikacji chronionych).

Zarządzanie wieloma sekretami aplikacji#

Bezpieczne aplikacje (maszyna-maszyna, tradycyjne web, Chronione) mogą teraz mieć wiele sekretów aplikacji z ustalonym terminem ważności. To umożliwia rotację sekretów i zapewnia jeszcze bezpieczniejsze doświadczenie.

Uwaga: Stary sekret stworzony przed wprowadzeniem tej funkcji nadal może być używany do uwierzytelniania klienta. Zaleca się jednak usunięcie starych i utworzenie nowych sekretów z terminem ważności dla zwiększenia bezpieczeństwa.

Kliknij, aby rozszerzyć aktualizacje Management API

• GET /api/applications/{applicationId}/secrets: Wylistuj wszystkie sekrety aplikacji.
• POST /api/applications/{applicationId}/secrets: Utwórz nowy sekret dla aplikacji.
• DELETE /api/applications/{applicationId}/secrets/{name}: Usuń sekret aplikacji po nazwie.
• PATCH /api/applications/{applicationId}/secrets/{name}: Zaktualizuj sekret aplikacji po nazwie.
• DELETE /api/applications/{applicationId}/legacy-secret: Usuń stary sekret aplikacji i zastąp go nowym.

Kliknij, aby rozszerzyć aktualizacje Konsoli

Aby zarządzać sekretami swojej aplikacji, przejdź do Logto Console -> Aplikacje -> Szczegóły aplikacji -> Punkty końcowe i poświadczenia.

Oryginalne pole wprowadzania sekretu aplikacji tylko do odczytu zostało zastąpione nową tabelą zarządzania sekretami. Możesz tworzyć, aktualizować i usuwać sekrety w tej tabeli.

Branding na poziomie organizacji i aplikacji#

Logo organizacji#

Teraz możliwe jest ustawienie jasnych i ciemnych logotypów dla organizacji. Można je przesłać na stronie ustawień organizacji.

Można również nadpisać logo doświadczenia logowania organizacji. Wystarczy dodać parametr organization_id do żądania autoryzacji. W większości SDK Logto można to zrobić za pomocą pola extraParams w metodzie signIn.

Na przykład w SDK JavaScript:

Wartość <organization-id> można znaleźć na stronie ustawień organizacji.

Jeśli nie możesz znaleźć pola extraParams w używanym przez ciebie SDK, daj nam znać.

Branding na poziomie aplikacji#

Teraz można ustawić loga, favikony i kolory dla swojej aplikacji. Te ustawienia będą używane w doświadczeniu logowania, gdy aplikacja rozpoczyna przepływ autoryzacji. Dla aplikacji, które nie mają ustawień brandingu, zostanie użyty branding omni doświadczenia logowania.

Jeśli w żądaniu autoryzacji zostanie podany organization_id, ustawienia brandingu aplikacji zostaną nadpisane przez ustawienia brandingu organizacji, jeśli są dostępne.

Usprawnienia wydajności#

Wsparcie dla rendering na serwerze aplikacji doświadczenia#

Logto teraz wstrzykuje ustawienia i frazy doświadczenia logowania do pliku index.html w celu poprawy wydajności pierwszego ekranu. Aplikacja doświadczenia nadal pobierze ustawienia i frazy z serwera, jeśli:

• Serwer nie wstrzyknął ustawień i fraz.
• Parametry w URL różnią się od danych renderowanych na serwerze.

Ulepszenia budowania pakietów#

• Używaj tsup do budowania pakietów connectorów. Dzięki temu proces budowania będzie szybszy, nie powinno to wpływać na funkcjonalność pakietów.
• Użyj Vite do transpilacji i bundlowania pakietów @logto/console, @logto/demo-app i @logto/experience. Usunięto ParcelJS i zastąpiono Vite. Nie powinno się spodziewać żadnych zmian łamiących.

Poprawki błędów#

Naprawiono zachowanie aktualizacji jsonb w punkcie końcowym PATCH /api/applications/{applicationId}#

Wszystkie pola jsonb w obiekcie Application powinny być aktualizowane w trybie replace, a nie w trybie merge. Ta zmiana sprawi, że metoda PATCH będzie bardziej przewidywalna i zgodna z projektem RESTful API.

• Zaktualizowano sposób aktualizacji pól jsonb z trybu merge na replace w punkcie końcowym PATCH /api/applications/{applicationId}.
• Zaktualizowano walidację parametrów wejściowych pola jsonb API z partial na full w punkcie końcowym PATCH /api/applications/{applicationId}.
• Dotknięte pola: oidc_client_metadata, custom_client_metadata, protected_app_metadata i custom_data.

Uwaga: Jeśli używasz Konsoli Logto do aktualizacji ustawień Application, nie powinieneś być dotknięty tą zmianą. Użytkownicy API, którzy używają metody PATCH do aktualizacji ustawień pola jsonb Application, powinni być świadomi tej zmiany. Metoda PATCH teraz zastąpi całe pole jsonb nowymi danymi wejściowymi. Każde częściowe dane wejściowe w dotkniętych polach zostaną odrzucone.

Naprawiono problem, w którym niektóre ładunki zdarzeń webhook zawsze zwracają kod statusu API 404#

Dotknięte zdarzenia webhook: Role.Scopes.Updated, Organizations.Membership.Updates.

Kod statusu odpowiedzi API zwrócony przez ładunek zdarzenia webhook zawsze wynosił 404. Było to spowodowane wstawieniem ładunku zdarzenia webhook przed ustawieniem kontekstu odpowiedzi API.

Ponieważ webhook jest wyzwalany tylko wtedy, gdy wydarzenie zostanie pomyślnie przetworzone, kod statusu powinien zawsze wynosić 2xx.

Problem został naprawiony, przenosząc wstawienie ładunku zdarzenia webhook po ustawieniu kontekstu odpowiedzi API.

Inne ulepszenia#

• Favikon dla ciemnego motywu można teraz ustawić w ustawieniach brandingu doświadczenia logowania.
• Dodano nowe algorytmy trawienia haseł: Argon2d i Argon2id. Użytkownicy z tymi algorytmami zostaną zmigrowani do Argon2i po pomyślnym zalogowaniu się.
• Konfiguracja listy przeglądarek dla @logto/experience została zsynchronizowana z tym, co jest opisane w README.md.
• Ulepszono opis autoryzacji swagger. Użyto natywnego schematu zabezpieczeń OAuth2 OpenAPI zamiast niestandardowego schematu zabezpieczeń opartego na nagłówkach HTTP.