Logto v1.43.0 fügt dynamische Apps mit OAuth Client-ID-Metadaten-Dokumenten, signierte SAML-Authentifizierungsanfragen, eine eingeschränkte Laufzeitumgebung für benutzerdefinierte JWTs und Aktionen, stärkere Token-Austausch-Validierung und erweiterten SSRF-Schutz für Webhooks sowie Enterprise-SSO hinzu.
CharlesDeveloper
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.
Logto v1.43.0 erweitert die Möglichkeiten, wie Anwendungen und Unternehmensidentitätsanbieter sich verbinden, während die Sicherheitsgrenzen rund um Token und ausgehende Anfragen gestärkt werden. Neu sind dynamische Apps mit OAuth Client-ID-Metadaten-Dokumenten, signierte SAML-Authentifizierungsanfragen und eine konsolidierte Laufzeitumgebung für benutzerdefinierte JWTs und Aktionen. Das Release verstärkt zudem den Schutz bei Token-Austausch, Webhooks und Enterprise-SSO, bringt Verbesserungen am Account Center, Unterstützung für Spanisch (Mexiko) und Zuverlässigkeitsverbesserungen. Hier das Neueste:
Die Anmeldung unterstützt jetzt es-MX (Spanisch, Mexiko).
Für Benutzer, deren Sprache Spanisch (Mexiko) ist, werden Telefonnummerneingaben standardmäßig mit der Landesvorwahl für Mexiko (+52) versehen. Dieses Release behebt außerdem Platzhalter für Listen-Formatierer und die noch nicht übersetzte MFA-Nachricht in den spanischen Sprachvarianten.
Ausgehende Anfragen, die über die Management-API konfiguriert werden, werden nun blockiert, wenn sie auf Loopback-, private, Link-Local-, Cloud-Metadaten- oder andere speziell genutzte Adressen aufgelöst werden.
Der Schutz umfasst nun:
Zustellung von Webhooks, inklusive POST /api/hooks/:id/test.
OIDC Enterprise-SSO-Discovery-, Token- und Userinfo-Anfragen.
SAML-Identitätsanbieter-Metadatenabfrage.
Jeden Redirect-Hop, den diese Anfragen ausführen.
DNS-Namen werden beim Verbindungsaufbau geprüft, sodass ein Hostname, der auf eine geschützte Adresse verweist, wie eine wörtliche IP-Adresse abgelehnt wird.
Zusätzlich zur Anforderung von First-Party-Subject-Tokens validiert Logto jetzt, dass ein als access_token-Subject präsentierter JWT tatsächlich ein Access Token ist.
Das JWT muss Folgendes enthalten:
Den RFC 9068 at+jwt header type.
Einen Anspruch client_id.
OIDC-ID-Tokens und andere von der Tenant signierte JWTs können nicht mehr anstelle eines Access-Tokens verwendet werden. Ungültige Subject-Tokens werden mit invalid_grant abgelehnt.
Einschränkungen der Account-API für Drittanbieter#
Drittanbieteranwendungen können Account-Daten nicht mehr über die Account-API oder die Verifizierungs-API verändern. Solche Anfragen geben jetzt zurück:
First-Party-Anwendungen einschließlich Account Center und Console sind nicht betroffen.
Für nicht aufgelöste Client-IDs wird die Prüfung verweigert. Dazu gehören gelöschte Anwendungen, deren Access Token noch aktiv sind, und CIMD-Clients, deren Kennung eine Metadaten-URL ist.
Kein Lese-Endpoint erhielt einen neuen direkten Schutz. Jedoch erfordern die folgenden Leseendpunkte Verifizierungsdatensätze, die durch geschützte Endpoints erstellt wurden und sind daher für Drittanbieteranwendungen nicht mehr erreichbar:
GET /api/my-account/grants
GET /api/my-account/sessions
GET /api/my-account/mfa-verifications/backup-codes
Gesperrte Benutzer können keine neuen Tokens erhalten#
Die Token-Ausgabe und Userinfo lehnen nun gesperrte Benutzer mit invalid_grant ab, wodurch das bestehende Verhalten für gelöschte Benutzer übernommen wird.
Dies gilt für alle Zugriffsarten wie Refresh Token, Autorisierungscode, Gerätecode und Token-Austausch, auch wenn ein früherer Token- oder Sitzungswiderruf nicht erfolgreich abgeschlossen wurde.
Drittanbieter-Anwendungsbereiche werden erneut validiert#
Das Entfernen eines Benutzerbereichs aus der Zustimmungskonfiguration einer Drittanbieteranwendung wirkt sich nun sowohl auf bestehende Grants als auch auf neue Autorisierungsanfragen aus.
Token-Austausch entfernt Bereiche, die nicht mehr konfiguriert sind.
Autorisierungsanfragen für bestehende Grants schlagen mit invalid_scope fehl, wenn angemessen.
Organisations-Tokenanfragen scheitern mit insufficient_scope, nachdem der organizations-Bereich entfernt wurde.
Die Zustimmung vergibt keinen Bereich mehr, der entfernt wurde, während der Consent-Bildschirm offen war.
Sentinel-Sperrzähler verwenden nun die gleiche normalisierte Form von Identifikatoren wie die Kontoabfrage:
E-Mail-Adressen werden kleingeschrieben.
Telefonnummern werden kanonisiert.
Benutzernamen werden nur bei einer nicht beachtenden Groß-/Kleinschreibung der Richtlinie der Tenant klein gefaltet.
So wird verhindert, dass alternative Schreibweisen desselben Identifikators getrennte Versuchsbuckets und damit eine Schwächung von maxAttempts generieren.
Die manuelle Entsperrung löscht außerdem äquivalente Schreibweisen, sofern sie demselben Konto zugeordnet sind. Nach dem Upgrade kann eine bestehende Sperre unter einer nicht-kanonischen Schreibweise vorzeitig enden, aber kein Benutzer wird stärker gesperrt als zuvor.
Das Widerrufen der Autorisierung einer Drittanbieteranwendung für einen Benutzer macht nun nur die Tokens dieser Anwendung ungültig. Die SSO-Sitzung im Browser bleibt aktiv.
Elliptische Kurvensignaturschlüssel zeigen jetzt den zu ihrer Kurve passenden Algorithmus an: P-256 nutzt ES256, P-384 nutzt ES384 und P-521 nutzt ES512.
Der Wechsel von Passkey-Login zu Verifizierungscode verhindert nun nicht mehr den Abschluss des CAPTCHA.
OIDC-Fehlermeldungen invalid_scope und insufficient_scope zeigen nun den abgelehnten Scope an statt des Roh-Platzhalters {{error_description}} oder {{scope}}.
Safari und andere Passwortmanager können jetzt ein sicheres Passwort auf Passwort-Erstell- und Zurücksetzbildschirmen mit dem richtigen Konto-Identifier vorschlagen und speichern.
Accept-Language-Quality-Werte mit Leerzeichen, wie en; q=0.7, werden jetzt korrekt geparst. Ungültige Werte werden sicher zurückgesetzt statt NaN zu erzeugen.
Gmail Custom Allowlist- und Blocklist-Vergleiche behandeln nun gmail.com und googlemail.com als gleichwertig und ignorieren Punkte im lokalen Teil.
Die Console bietet jetzt klarere Beispiele, Beschreibungen und kürzere Platzhalter für eigene E-Mail-Regeln.
Beim Speichern von Account Center oder Anmeldeeinstellungen werden nun Verweise auf gelöschte benutzerdefinierte Profilfelder entfernt anstatt custom_profile_fields.entity_not_exists_with_names zurückzugeben.
Gelöschte Felder können weiterhin aus der Console entfernt werden, auch wenn ihre Berechtigungssteuerung auf "Aus" steht.
Die Relation-Endpunkte der Management-API akzeptieren jetzt leere Scope- oder Rollen-Arrays als No-Op und geben keinen 500-Fehler mehr zurück. Dies betrifft Endpunkte wie:
POST /applications/:applicationId/user-consent-scopes
POST /organizations/:id/users/:userId/roles
Die Datumsvalidierung entspricht jetzt der gesamten Eingabe und lehnt angehängte Zeichen nach einem sonst gültigen Datum ab.
Webhook-POST-Anfragen werden jetzt bis zu dreimal wiederholt, wenn der Endpoint einen HTTP-5xx-Status zurückgibt, entsprechend der dokumentierten Zustellvereinbarung.
Da ein wiederholtes Event möglicherweise mehr als einmal zugestellt wird, sollten Empfänger von Webhooks Events idempotent verarbeiten.
Der Microsoft-Azure-AD-Konnektor unterstützt jetzt eine Option disableEmailSync.
Standardmäßig kopiert der Konnektor weiterhin das Microsoft-Graph-mail-Attribut in das Logto-Benutzerprofil. Aktiviere diese Option, wenn der Konnektor den Benutzer authentifizieren, aber diese Adresse nicht synchronisieren soll – entsprechend der bisherigen Einstellung für Azure OIDC Enterprise SSO.
Aktion erforderlich — Outbound-Request-Schutz: Wenn Webhooks oder Enterprise-SSO-Konnektoren absichtlich auf Services im privaten Netzwerk zugreifen, füge die benötigten IP-Adressen oder CIDR-Bereiche vor dem Upgrade zu SSRF_ALLOWED_ADDRESSES hinzu:
Nur die benötigten Ziele auf die Allowlist zu setzen ist sicherer, als den Schutz global zu deaktivieren.
Kompatibilität für dynamische Apps: Das Konfigurieren von SSRF_ALLOWED_ADDRESSES deaktiviert CIMD, sodass nicht authentifizierte dynamische Clients die Allowlist nicht für den Zugriff auf private Dienste verwenden können. Die Einstellung SSRF_PROTECTION_DISABLED=true deaktiviert ebenfalls CIMD.
Kompatibilität der Konfiguration: OIDC_PROVIDER_SSRF_PROTECTION_DISABLED bleibt als Alias für SSRF_PROTECTION_DISABLED unterstützt. Diese Variablen gelten nur für selbstgehostete Deployments.
Limits für Skriptlaufzeit: Benutzerdefinierte JWT- und Aktionsskripte müssen innerhalb von 5 Sekunden abgeschlossen sein, im Arbeitsspeicherbudget von 128 MB bleiben und JSON-serielle Werte zurückgeben.
Datenbankmigration erforderlich: Dieses Release enthält neue Schemaveränderungen und Indizes. Nach dem Upgrade führe den Befehl zur Datenbankschemaveränderung (npm run alteration deploy im @logto/cli/core-Image oder logto db alteration deploy) vor dem Start der neuen Version aus. Siehe die Upgrade-Anleitung.
