Logto product updates
Logto v1.41.0 brings app-level access control, password expiration policies, major Account Center upgrades, configurable username and verification-code rules, safer message delivery, and a round of protocol/security hardening.
Logto v1.41.0 brings app-level access control, password expiration policies, major Account Center upgrades, configurable username and verification-code rules, safer message delivery, and a round of protocol/security hardening.
Logto v1.41.0 is a control-and-security release. It gives teams finer ways to decide who can access each app, more complete password lifecycle controls, and a much more capable Account Center for end users. It also tightens verification-code delivery, username rules, SAML/OIDC handling, MFA replay protection, and self-hosting upgrade paths. Here's what's new.
You can now restrict access to an application directly from Logto. Access rules can target specific users, user roles, organizations, or organization roles.
When a user does not match the configured rule set, Logto blocks the sign-in or app access flow with an access denied page instead of letting the request continue. This makes app rollout, customer-specific access, internal-tool protection, and organization-scoped access easier to manage without pushing the full decision into your application code.
See the app-level access control docs for the full setup flow.
Console now supports tenant-level password expiration under Security > Password policy.
Admins can enable password expiration, configure how many days a password stays valid, and manually expire a specific user's password from the user details page. When a password expires, the user must reset it through the configured recovery method before password sign-in can continue.
SSO and passkey sign-ins are not affected. Existing users without a recorded password-change timestamp are handled gracefully: Logto anchors them to the time the policy is enabled, so they get the full valid period instead of being expired immediately.
Account Center continues to grow into a full self-service identity surface for end users.
This release adds session management, connected third-party application review, profile management, avatar upload, avatar upload during collect-profile sign-up, independent passkey controls, and a user-facing preference for passkey sign-in prompts.
The Account Center profile page, custom profile fields at sign-up, and avatar upload endpoints are also now released from dev feature gates.
A few important fixes landed here too:
Tenant-level username rules are now configurable from Console > Sign-in experience > Sign-up and sign-in > Advanced options.
The policy covers case sensitivity, length bounds, and allowed character types. It is enforced across end-user username writes, including sign-up, profile fulfillment, Account Center, Account API, and /me.
Switching to case-insensitive usernames is guarded: Logto checks for existing usernames that differ only by case and blocks the policy change until conflicts are resolved. The OIDC preferred_username claim now also falls back to the user's username when profile.preferredUsername is unset.
Verification-code controls also move into Console security settings. Admins can configure verification-code expiration duration and maximum retry attempts.
Logto now applies a system-level per-recipient send rate limit across email/SMS verification and invitation send paths, including Experience, MFA, Account API, Management API, /me, organization invitations, and the legacy interaction API.
When a send is throttled, Logto emits a Message.RateLimited webhook event, which is now selectable in Console webhook settings.
Verification-code delivery to unknown recipients is also suppressed when registration is disabled, reducing account enumeration risk.
For organization API resource tokens, the access token JWT customizer now receives context.organization with the target organization's id, name, description, and customData.
This makes it easier to add per-organization claims without embedding every organization mapping into every token.
A couple of API improvements landed as well:
POST /api/applications/:applicationId/roles is now idempotent. Existing role IDs are ignored instead of returning 422 application.role_exists.201 with { roleIds, addedRoleIds }, matching the user role assignment API shape.This release includes a focused set of protocol and security fixes:
samlify is upgraded to ^2.13.0 for improved XML escaping in generated SAML assertions.400 invalid_request.Compatibility and storage fixes are included too: older Safari and iOS 15 no longer crash on startup due to unsupported regex lookbehind syntax, OIDC enterprise connectors can fetch discovery configuration from providers that reject JSON-only response negotiation, and custom UI asset Azure Blob transport failures now map to retryable storage download errors.
This release adds and improves several connector-related capabilities:
samlify and its stricter return types.A database migration is required for v1.41.0. This release ships schema alterations for password expiration, username policy, verification-code policy, message-rate sentinel indexes, Account Center defaults, and service-log indexes.
After upgrading, run the database alteration command before starting the new version. See the upgrade guide for details.
The CASE_SENSITIVE_USERNAME environment variable is now deprecated. It still works as a runtime override, but username case sensitivity should be configured per tenant through the new username policy. The environment variable is scheduled for removal in the next major version.
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.