Logto v1.39.0 ist da und bietet sichereres Signierschlüssel-Rotationsverfahren, intelligentere JWT-Skript-Fehlerbehandlung, erweiterte Sicherheitskontrollen im Account Center, Unterstützung für WhatsApp-Connector sowie wichtige Sicherheitsverbesserungen.
SimengDeveloper
Verschwenden Sie keine Wochen mit Benutzerauthentifizierung
Bringen Sie sichere Apps schneller mit Logto auf den Markt. Integrieren Sie Benutzerauthentifizierung in Minuten und konzentrieren Sie sich auf Ihr Kernprodukt.
Wir freuen uns, Logto v1.39.0 vorzustellen – eine Version, die auf stärkere betriebliche Sicherheit, flexiblere Token-Anpassung und erhöhten Kontoschutz für Endnutzer abzielt. Diese Version führt eine Schonfrist für die Drehung privater Signierschlüssel ein, konfigurierbare Fehlerbehandlung für benutzerdefinierte JWT-Skripte, eine neue Sicherheitsseite im Account Center, WhatsApp-Connector-Unterstützung über die Meta Cloud API und mehrere Verbesserungen bei Sicherheit und Zuverlässigkeit in Authentifizierungsabläufen.
Schonfrist für Rotation privater Signierschlüssel: Logto unterstützt jetzt eine Schonfrist beim Rotieren privater Signierschlüssel, sodass Clients ihren zwischengespeicherten JWKS ohne Ausfallzeiten aktualisieren können.
Fehlerbehandlung für benutzerdefinierte JWT-Skripte: Die Anpassung von Access Token und Client Credentials JWT kann jetzt die Token-Ausgabe blockieren, wenn Skripte fehlschlagen.
Sicherheitsseite im Account Center: Endnutzer können ab sofort Social Accounts verknüpfen/entfernen, MFA nutzen und Kontolöschungen im Account Center verwalten.
WhatsApp-Connector: Über die Meta Cloud API steht jetzt ein neuer WhatsApp-SMS-Connector zur Verfügung.
Sicherheits- und Kompatibilitätsfixes: Die Rückmeldungen bei "Passwort vergessen" sind jetzt vereinheitlicht, um das Risiko der Kontoermittlung zu reduzieren, und Social/SSO-Weiterleitungen in In-App-Browsern sind robuster.
Fehlerbehandlung für benutzerdefinierte JWT-Skripte#
Logto unterstützt nun konfigurierbare Fehlerbehandlung für benutzerdefinierte JWT-Skripte, die in Access-Token- und Client-Credentials-Flows verwendet werden.
Enthaltene Änderungen:
Benutzerdefinierte JWT-Skripte können jetzt die Token-Ausgabe blockieren, wenn die Ausführung fehlschlägt.
api.denyAccess() bleibt als access_denied-Antwort bestehen.
Andere Skriptfehler im Blocking-Modus werden als lokalisierte invalid_request-Antworten zurückgegeben.
In der Console gibt es nun einen eigenen Fehlerbehandlung-Tab zur Konfiguration des Verhaltens.
Bei neuen Skripten ist blockIssuanceOnError standardmäßig aktiviert.
Bestehende Skripte ohne gespeicherten Wert behalten das bislang deaktivierte Verhalten bei.
Zugehörige Hinweise, Phrasen, Schemas und Integrationsabdeckung in der Console wurden aktualisiert.
Das hilft Entwickler:innen, zu wählen, ob Token-Anpassungsfehler offen oder geschlossen behandelt werden sollen – je nach Sicherheitsanforderung.
APIs zur Zuweisung von Organisationsnutzern und -rollen liefern jetzt Antwort-Bodies.
Aktualisierte Endpunkte:
POST /organizations/:id/users gibt jetzt { userIds: string[] } zurück und spiegelt die im Request gesendeten Nutzer-IDs wider.
POST /organizations/:id/users/:userId/roles gibt jetzt { organizationRoleIds: string[] } zurück, enthält deduplizierte Rollen-IDs des Nutzers inklusive durch Rollennamen aufgelöster IDs.
Die Passwort-vergessen-Verifizierung liefert jetzt immer einen einheitlichen Fehler verification_code.code_mismatch zurück.
Dadurch wird vermieden, dass durch unterschiedliche Fehlermeldungen ersichtlich ist, ob eine E-Mail-Adresse oder Telefonnummer existiert.
Social- und SSO-Weiterleitungen in In-App-Browsern#
Die Zuverlässigkeit von Social- und SSO-Weiterleitungen in In-App-Browsern wie Instagram, Facebook und LINE wurde verbessert.
Einige In-App-Browser öffnen OAuth-Seiten von Identitätsanbietern in einer neuen WebView, was dazu führen kann, dass sessionStorage nach der Rückleitung verloren geht.
Dieses Release fügt einen Fallback auf localStorage hinzu:
Der Weiterleitungszustand wird weiterhin im sessionStorage gespeichert.
Ein alternativer Kontext-Bundle für Weiterleitungen wird auch im localStorage gespeichert.
Beim Callback stellt Logto den Zustand aus localStorage wieder her, falls sessionStorage fehlt.
Fallback-Einträge werden beim Lesen verbraucht und nach 10 Minuten automatisch entfernt.
Sind beide Speicher leer, erscheint ein Fehlertoast beim Nutzer.
