Logto v1.42.0 bringt benutzerdefinierte Domain-Verifizierungsdateien, E-Mail-Positivlisten mit Wildcard-Mustern, Magic Links für das Zurücksetzen von Passwörtern, ein Grant.LimitExceeded Webhook, sowie Refresh auf Protokollebene mit node-oidc-provider v9, Koa 3 und standardmäßig aktivem SSRF-Schutz.
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.
Logto v1.42.0 ist ein Release, das sich auf Domains und Protokolle konzentriert. Es ermöglicht Teams, die Inhaberschaft einer Domain nachzuweisen, ohne einen zusätzlichen Host bereitzustellen, bietet feinere Kontrolle darüber, welche E-Mails Zugang zu einer Tenant erhalten können, und sorgt für einen reibungsloseren Passwort-Reset-Prozess für Endnutzer. Unter der Haube wechselt Logto auf node-oidc-provider v9 und Koa 3 und aktiviert SSRF-Schutz standardmäßig für ausgehende OIDC-Anfragen. Hier ist, was neu ist.
Drittanbieterdienste überprüfen oft die Domain-Inhaberschaft, indem sie dich auffordern, eine kleine Datei unter einem festen Pfad bereitzustellen. Bisher bedeutete das, einen separaten Host neben deiner Logto-Custom-Domain zu betreiben.
Du kannst jetzt Verifizierungsdateien an eine aktive Custom-Domain anhängen unter Konsole > Tenant-Einstellungen > Domains. Jede Datei besitzt:
Einen Pfad, der entweder ein Dateiname auf Root-Ebene mit Endung ist (zum Beispiel /verify.txt) oder ein Pfad unter /.well-known/.
Einen Inhaltstyp von text/plain oder application/json. JSON-Inhalte werden beim Speichern validiert.
Inhalte bis zu 16 KB Größe.
Pro Domain können bis zu 10 Dateien konfiguriert werden, die Pfade müssen eindeutig sein. Logto liefert exakte GET- und HEAD-Treffer mit dem festgelegten Inhaltstyp und Antworthärtung aus. Bestehende Logto-Routen haben immer Vorrang vor einer Verifizierungsdatei am selben Pfad, eine falsch konfigurierte Datei kann also niemals einen echten Endpunkt überschreiben. Die Konsolen-Erfahrung ist in allen unterstützten Sprachen lokalisiert.
Da Logto sich aus den Datei-Inhalten heraushält, funktioniert dies bei jedem Anbieter-Verifizierungsschema, ohne dass Logto anbieter-spezifisches Verhalten modellieren muss.
E-Mail-Zugriffsregeln: Positivliste und Wildcard-Muster#
Die E-Mail-Blocklist-Policy wird zu einem umfassenden Satz von E-Mail-Zugriffsregeln, konfiguriert unter Konsole > Sicherheit > E-Mail-Blocklist.
Benutzerdefinierte E-Mail-Positivliste. Konfiguriere eine Positivliste von E-Mail-Adressen, Domains oder Wildcard-Mustern. Wenn die Positivliste gesetzt ist, werden nur übereinstimmende E-Mails für neue Registrierungen und neu verknüpfte E-Mails akzeptiert – sowohl bei der E-Mail-Registrierung als auch beim Aktualisieren der Kontoadresse.
Wildcard-Muster. Sowohl Positiv- als auch Blockliste akzeptieren Wildcard-Adressen und -Domainmuster, wie foo*@example.com, *@example.com und @*.example.com, neben exakten Adressen ([email protected]) und Domains (@example.com).
Konfliktwarnungen. Die Konsole warnt, wenn ein Positivlisteneintrag auch eine Blockregel trifft, wenn ein Positivlisteneintrag ein Pluszeichen verwendet, während E-Mail-Subaddressing blockiert ist, und wenn die kombinierten Regeln gar keine neue E-Mail durchlassen würden.
Die Matching- und Validierungslogik wird durch wiederverwendbare Helfer in @logto/core-kit bereitgestellt, also gelten überall dieselben Regeln, wo eine E-Mail in einen Tenant gelangt.
Die Experience-App unterstützt jetzt Passwort-Reset-Flows, die Einmal-Token-Magic-Links direkt auf der Passwort-zurücksetzen-Seite überprüfen – zusätzlich zu Verifizierungscodes.
Wenn OIDC Grants entfernt werden, weil eine Anwendung ihr maximales Grant-Limit überschritten hat, feuert Logto jetzt ein Grant.LimitExceeded Webhook-Ereignis, das wie jedes andere Ereignis in den Webhook-Einstellungen der Konsole auswählbar ist.
Die Nutzlast berichtet userId, applicationId, revokedGrantIds, maxAllowedGrants und preRevocationActiveGrantCount. Die Zustellung erfolgt Fire-and-Forget: Fehler werden als TriggerHook.Grant.LimitExceeded Einträge im Audit-Log aufgezeichnet und blockieren niemals die Authentifizierungsantwort.
OIDC-Provider auf node-oidc-provider v9 aktualisiert#
Die größte Änderung hier ist ein Sicherheitsfix bei der Tokenaufhebung.
Das Widerrufen eines undurchsichtigen Zugriffstokens widerruft jetzt auch jedes Token unter demselben Grant, inklusive Refresh-Token. In v8 blieb das Refresh-Token nach Widerruf weiterhin nutzbar und konnte neue Access-Tokens anfordern.
Weitere Protokollupdates in v9:
Der Revocation-Endpunkt lehnt jetzt JWT-Access-Tokens mit unsupported_token_type ab, statt einen Erfolg zurückzugeben, ohne tatsächlich etwas zu widerrufen wie in v8.
Der RFC 8414 Authorization Server Metadata Endpunkt ist verfügbar unter /oidc/.well-known/oauth-authorization-server.
Der redundante at_hash Claim wird aus ID-Tokens entfernt, die am Token-Endpunkt ausgegeben werden.
ID-Tokens enthalten nicht mehr den optionalen Header typ: "JWT". OpenID Connect definiert ID-Tokens als JWTs und verlangt nicht, dass Clients diesen Header überprüfen.
Handlungsbedarf bei individueller ID-Token-Verifizierung. Es ist keine Aktion nötig, wenn du ein offizielles Logto SDK nutzt. Wenn deine Integration eine eigene ID-Token-Verifizierung durchführt, passe sie an, damit das Fehlen von at_hash und des Headers typ: "JWT" erlaubt ist.
Logto läuft jetzt auf Koa 3, der aktiv gepflegten Hauptversion, die Koas Sicherheitsupdates als erste erhält. Es ist kein Verhaltensänderung zu erwarten: Alle Endpunkte, OIDC-Flows und API-Antworten verhalten sich wie zuvor.
Interne Application-Secrets werden nicht länger über Management-APIs preisgegeben.
Die E-Mail-Blocklist-Policy wird in öffentlichen Sign-In-Experience-Antworten nicht mehr zurückgegeben.
Das Abrufen gespeicherter Third-Party-Provider-Access-Tokens über die Account API benötigt jetzt den identities-User-Scope, analog zu den anderen Social- und Enterprise-SSO-Endpoints.
Account-API-Verifizierungscodes werden nicht mehr an blockierte E-Mail-Adressen verschickt.
E-Mail und E-Mail-Domänenvalidierung matchen jetzt vollständige Werte und erzwingen strengere Domain-Labels.
Verbesserungen bei Benutzererlebnis, Speicherung und Stabilität#
Wenn ein Social- oder SSO-Registrierungs-Flow durch E-Mail-Zugriffsregeln abgelehnt wird, führt die Fehlerbestätigung den Nutzer jetzt auf die Logto-Anmeldeseite zurück, statt zurück zum externen Identity Provider zu navigieren.
MFA wird jetzt automatisch aktiviert, sobald ein Nutzer einen Faktor über die Account-APIs bindet.
Das Erstellen eines neuen E-Mail- oder SMS-Konnektors führt das Einfügen und das Aufräumen alter Konnektoren in einer einzelnen Datenbanktransaktion durch. Zuvor konnte ein Absturz zwischen den beiden Anweisungen doppelte Konnektoren hinterlassen.
Redis-Cluster-Anmeldedaten werden jetzt percent-decoded, sodass Verbindungen auch funktionieren, wenn Benutzernamen oder Passwort URL-Reservierte Zeichen enthalten.
TLS ist jetzt korrekt aktiviert für Redis-Cluster-Verbindungen, die das rediss-Protokoll nutzen.
jose v6: Die Apple-, Google-, OAuth- und OIDC-Konnektoren nutzen jetzt jose 6, das auf der Web Crypto API statt Nodes crypto-Modul läuft. Token-Signierung und ID-Token-Verifizierung verhalten sich genau wie bisher.
GitLab: Die nicht benötigte jose-Abhängigkeit wurde entfernt, das Installieren des Konnektors zieht das Paket also nicht länger unnötig mit.
Aliyun SMS: Hongkonger Telefonnummern werden jetzt als Auslandnummern behandelt.
Aliyun SMS Authentifizierungsservice (MAS): Die Signatur wird jetzt als Freitext eingegeben statt als Dropdown, damit es auch bei erneuter Signaturrotation von Aliyun weiterhin funktioniert.
Handlungsbedarf — OIDC-Provider SSRF-Schutz. Die Sicherheit ausgehender Anfragen wurde gestärkt und SSRF-Schutz ist jetzt standardmäßig aktiviert. Self-Hosted-Deployments, die vertrauenswürdige Relying-Party-Endpunkte in privaten Netzwerken erreichen müssen, müssen OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true setzen, bevor Logto gestartet wird; andernfalls bleibt die Variable unset.
Datenbankmigration erforderlich. Dieses Release enthält Schema-Anpassungen für benutzerdefinierte Domain-Verifizierungsdateien sowie interne Indizes und Tabellen. Nach dem Upgrade, führe den Datenbank-Änderungsbefehl aus (npm run alteration deploy im @logto/cli/core Image oder logto db alteration deploy), bevor die neue Version gestartet wird. Siehe den Upgrade-Guide für Details.
Custom-ID-Token-Verifizierung. Siehe oben den Abschnitt zu node-oidc-provider v9 bezüglich der at_hash und typ Header-Änderungen.
