Logto v1.42.0 brings custom domain verification files, email allowlists with wildcard patterns, reset-password magic links, a Grant.LimitExceeded webhook, and a protocol-layer refresh with node-oidc-provider v9, Koa 3, and SSRF protection on by default.
Logto v1.42.0 is a domains-and-protocol release. It gives teams a way to prove domain ownership without standing up another host, finer control over which emails can enter a tenant, and a smoother password reset path for end users. Under the hood, it moves Logto onto node-oidc-provider v9 and Koa 3, and turns on SSRF protection for outbound OIDC requests by default. Here's what's new.
Third-party services often verify domain ownership by asking you to serve a small file at a fixed path. Until now that meant running a separate host alongside your Logto custom domain.
You can now attach verification files to an active custom domain from Console > Tenant settings > Domains. Each file has:
/verify.txt) or a path under /.well-known/.text/plain or application/json. JSON content is validated on save.Up to 10 files can be configured per domain, and paths must be unique. Logto serves exact GET and HEAD matches with the configured content type and response hardening. Existing Logto routes always take precedence over a verification file at the same path, so a misconfigured file can never shadow a real endpoint. The Console experience is localized across all supported languages.
Because Logto stays out of the file contents, this works for any provider's verification scheme without Logto having to model provider-specific behavior.
The email blocklist policy grows into a fuller set of email access rules, configured in Console > Security > Email blocklist.
Custom email allowlist. Configure an allowlist of email addresses, domains, or wildcard patterns. When the allowlist is set, only matching emails are accepted for new sign-ups and newly linked emails — on both email registration and account email updates.
Wildcard patterns. The allowlist and the blocklist both accept wildcard address and domain patterns, such as foo*@example.com, *@example.com, and @*.example.com, alongside exact addresses ([email protected]) and domains (@example.com).
Conflict warnings. Console warns when an allowlist entry also matches a block rule, when an allowlist entry uses a plus sign while email subaddressing is blocked, and when the combined rules would let no new email through at all.
The matching and validation logic is shared through reusable helpers in @logto/core-kit, so the same rules apply everywhere an email enters a tenant.
The Experience app now supports password reset flows that verify one-time-token magic links directly from the reset password landing page, in addition to verification codes.
Grant.LimitExceeded webhook eventWhen OIDC grants are evicted because an application exceeded its max allowed grants limit, Logto now fires a Grant.LimitExceeded webhook event, selectable in Console webhook settings like any other event.
The payload reports userId, applicationId, revokedGrantIds, maxAllowedGrants, and preRevocationActiveGrantCount. Dispatch is fire-and-forget: failures are recorded as TriggerHook.Grant.LimitExceeded audit log entries and never block the authentication response.
The biggest change here is a security fix in token revocation.
Revoking an opaque access token now also revokes every token under the same grant, including the refresh token. In v8, the refresh token stayed usable after revocation and could keep requesting new access tokens.
Other protocol updates in v9:
unsupported_token_type, instead of returning a success response without actually revoking anything as in v8./oidc/.well-known/oauth-authorization-server.at_hash claim is removed from ID tokens issued at the token endpoint.typ: "JWT" header. OpenID Connect defines ID tokens as JWTs and does not require clients to verify this header.Action required for custom ID token verification. No action is required when using an official Logto SDK. If your integration performs custom ID token verification, update it to allow the at_hash claim to be absent, and to allow the typ: "JWT" header to be absent.
Logto now runs on Koa 3, the actively maintained release line that receives Koa's security fixes first. No behavior change is expected: all endpoints, OIDC flows, and API responses behave exactly as before.
identities user scope, matching the other social and enterprise SSO identity endpoints.rediss protocol.jose dependency, so installing the connector no longer pulls in a package it never imported.Action required — OIDC provider SSRF protection. Outbound request security is strengthened and SSRF protection is now enabled by default. Self-hosted deployments that need to reach trusted relying-party endpoints on private networks must set OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true before starting Logto; otherwise leave the variable unset.
Database migration required. This release ships schema alterations for custom domain verification files, plus internal indexes and tables. After upgrading, run the database alteration command (npm run alteration deploy in the @logto/cli/core image, or logto db alteration deploy) before starting the new version. See the upgrade guide for details.
Custom ID token verification. See the node-oidc-provider v9 section above for the at_hash and typ header changes.
Huge thanks to the community members whose work shipped in this release:
Grant.LimitExceeded webhook event (#9230) and transactional passwordless connector replacement (#9277)rediss TLS fix (#9144)Ready to upgrade? Check out the upgrade guide for step-by-step instructions.
For the complete list of changes, see the GitHub release page.
Have questions or feedback? Join us on Discord or open an issue on GitHub.