Logto v1.42.0 brengt aangepaste domeinverificatiebestanden, e-mailtoegangsregels met wildcardpatronen, wachtwoordherstel magic links, een Grant.LimitExceeded webhook en een protocol-laag upgrade met node-oidc-provider v9, Koa 3, en standaard SSRF-bescherming.
Logto v1.42.0 is een release gericht op domeinen en protocollen. Het geeft teams een manier om domeineigendom te bewijzen zonder een aparte host op te zetten, fijnmazigere controle over welke e-mails in een tenant mogen, en een soepelere wachtwoordherstelervaring voor eindgebruikers. Onder de motorkap brengt het Logto naar node-oidc-provider v9 en Koa 3, en schakelt SSRF-bescherming standaard in voor uitgaande OIDC-verzoeken. Dit is er nieuw.
Diensten van derden verifiëren vaak domeineigendom door je te vragen een klein bestand te serveren op een vast pad. Tot nu toe betekende dit dat je een aparte host naast je Logto-aangepaste domein moest draaien.
Je kunt nu verificatiebestanden toevoegen aan een actief aangepast domein via Console > Tenantinstellingen > Domeinen. Elk bestand heeft:
/verify.txt) of een pad onder /.well-known/.text/plain of application/json. JSON-inhoud wordt gevalideerd bij opslaan.Er kunnen maximaal 10 bestanden per domein worden geconfigureerd, en paden moeten uniek zijn. Logto levert exacte GET en HEAD-matches met het ingestelde contenttype en geharcodeerde respons. Bestaande Logto-routes hebben altijd voorrang boven een verificatiebestand op hetzelfde pad, dus een verkeerd geconfigureerd bestand kan nooit een echte endpoint overschrijven. De Console-ervaring is gelokaliseerd voor alle ondersteunde talen.
Omdat Logto zich niet bemoeit met de inhoud van de bestanden, werkt dit voor elke provider's verificatieschema zonder dat Logto specifieke providerlogica hoeft te implementeren.
Het e-mail blocklistbeleid groeit uit tot een uitgebreider set e-mailtoegangsregels, instelbaar via Console > Beveiliging > E-mail blocklist.
Aangepaste e-mail allowlist. Stel een allowlist in met e-mailadressen, domeinen of wildcardpatronen. Als de allowlist actief is, worden alleen overeenkomende e-mails geaccepteerd voor nieuwe registraties en nieuw gekoppelde e-mails — zowel bij e-mailregistratie als het bijwerken van een account-e-mailadres.
Wildcardpatronen. Zowel de allowlist als de blocklist accepteren wildcardpatronen voor adressen en domeinen, zoals foo*@example.com, *@example.com en @*.example.com, naast exacte adressen ([email protected]) en domeinen (@example.com).
Conflictwarnigen. Console waarschuwt als een allowlistitem ook overeenkomt met een blockregel, als een allowlistitem een plusteken gebruikt terwijl e-mail-subaddressing geblokkeerd is, en als de gecombineerde regels geen nieuwe e-mails meer toelaten.
De match- en validatielogica wordt gedeeld via herbruikbare helpers in @logto/core-kit, zodat overal waar een e-mail een tenant binnenkomt dezelfde regels gelden.
De Experience-app ondersteunt nu wachtwoordherstelflows die eenmalige magic links direct vanaf de reset-wachtwoord landingspagina verifiëren, naast verificatiecodes.
Grant.LimitExceeded webhook eventWanneer OIDC-grants worden verwijderd omdat een applicatie het maximaal toegestane aantal grants overschreed, stuurt Logto nu een Grant.LimitExceeded webhook event, instelbaar in de Console-webhookinstellingen zoals elk ander event.
De payload rapporteert userId, applicationId, revokedGrantIds, maxAllowedGrants en preRevocationActiveGrantCount. Dispatch is fire-and-forget: mislukte pogingen worden geregistreerd als TriggerHook.Grant.LimitExceeded auditlogboekvermeldingen en blokkeren nooit de authenticatierespons.
De grootste wijziging hier is een beveiligingsfix bij het intrekken van tokens.
Het intrekken van een opaque access token trekt nu ook elk token onder dezelfde grant in, inclusief de refresh token. In v8 bleef de refresh token bruikbaar na intrekking en kon die nog steeds nieuwe acces tokens blijven aanvragen.
Andere protocolwijzigingen in v9:
unsupported_token_type, in plaats van een succesresponse terug te geven zonder daadwerkelijk iets in te trekken zoals in v8./oidc/.well-known/oauth-authorization-server.at_hash claim is verwijderd uit ID-tokens die bij het token endpoint uitgegeven worden.typ: "JWT" header. OpenID Connect definieert ID-tokens als JWTs en vereist niet dat clients deze header controleren.Actie vereist voor aangepaste ID-tokenverificatie. Geen actie nodig bij gebruik van een officiële Logto SDK. Als je integratie eigen ID-tokenverificatie uitvoert, werk deze dan bij zodat afwezige at_hash claims én de afwezigheid van de typ: "JWT" header zijn toegestaan.
Logto draait nu op Koa 3, de actief onderhouden release die Koa's beveiligingsupdates als eerste krijgt. Er wordt geen gedragverandering verwacht: alle endpoints, OIDC-flows en API-responses werken precies als voorheen.
identities, gelijk aan de andere social- en enterprise-SSO-identiteitsendpoints.rediss protocol gebruiken.jose dependency is verwijderd, zodat het installeren van de connector geen niet-gebruikte package meer binnenhaalt.Actie vereist — OIDC-provider SSRF-bescherming. De beveiliging van uitgaande verzoeken is aangescherpt en SSRF-bescherming is nu standaard ingeschakeld. Self-hosted deployments die vertrouwde endpoints op private netwerken moeten bereiken, moeten OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true zetten voor het starten van Logto; anders deze variabele niet instellen.
Database-migratie vereist. Deze release brengt schema-aanpassingen voor aangepaste domeinverificatiebestanden, plus interne indexen en tabellen. Na de upgrade, draai het database-aanpassingscommando (npm run alteration deploy in het @logto/cli/core image, of logto db alteration deploy) voordat je de nieuwe versie start. Zie de upgrade-gids voor details.
Aangepaste ID-tokenverificatie. Zie hiervoor de node-oidc-provider v9 sectie hierboven voor de wijzigingen aan de at_hash claim en typ header.
Veel dank aan de communityleden wiens werk verscheept is in deze release:
Grant.LimitExceeded webhook event (#9230) en transactionele vervanging van wachtwoordloze connector (#9277)rediss TLS-fix (#9144)Klaar om te upgraden? Bekijk de upgrade-gids voor stapsgewijze instructies.
Voor de complete lijst van wijzigingen, zie de GitHub releasepagina.
Heb je vragen of feedback? Kom bij ons op Discord of open een issue op GitHub.