Logto v1.43.0 adds dynamic apps with OAuth Client ID Metadata Documents, signed SAML authentication requests, a bounded Custom JWT and Actions runtime, stronger token exchange validation, and expanded SSRF protection for webhooks and enterprise SSO.

Logto v1.43.0 expands how applications and enterprise identity providers connect while strengthening security boundaries around tokens and outbound requests. It introduces dynamic apps with OAuth Client ID Metadata Documents, signed SAML authentication requests, and a consolidated runtime for Custom JWT and Actions. The release also hardens token exchange, webhooks, and enterprise SSO, alongside Account Center improvements, Spanish (Mexico) support, and reliability fixes. Here's what's new.

Sign-in Experience

Sign-in Experience now supports es-MX (Spanish, Mexico).

For users whose language is Spanish (Mexico), phone inputs default to the Mexico country code (+52). This release also fixes list formatter placeholders and the remaining untranslated MFA message in the Spanish locales.

Security hardening

SSRF protection for webhooks and enterprise SSO

Outbound requests configured through the Management API are now blocked when they resolve to loopback, private, link-local, cloud metadata, or other special-use addresses.

Protection now covers:

• Webhook delivery, including POST /api/hooks/:id/test.
• OIDC enterprise SSO discovery, token, and userinfo requests.
• SAML identity-provider metadata fetching.
• Every redirect hop made by these requests.

DNS names are checked when the connection is established, so a hostname that resolves to a protected address is rejected like a literal IP address.

Token exchange validation

In addition to requiring first-party subject tokens, Logto now validates that a JWT presented as an access_token subject is actually an access token.

The JWT must contain:

• The RFC 9068 at+jwt type header.
• A client_id claim.

OIDC ID tokens and other JWTs signed by the tenant can no longer be substituted for an access token. Invalid subject tokens are rejected with invalid_grant.

Third-party Account API restrictions

Third-party applications can no longer mutate account data through the Account API or Verification API. Such requests now return:
403 auth.third_party_application_forbidden

First-party applications, including Account Center and Console, are unaffected.

The check fails closed for unresolved client identifiers. This includes deleted applications whose access tokens are still active and CIMD clients whose identifier is a metadata URL.

No read route received a new direct guard. However, the following reads require verification records created through guarded routes and are therefore no longer reachable by third-party applications:

• GET /api/my-account/grants
• GET /api/my-account/sessions
• GET /api/my-account/mfa-verifications/backup-codes

Suspended users cannot receive new tokens

Token issuance and userinfo now reject suspended users with invalid_grant, matching the existing behavior for deleted users.

This applies across refresh token, authorization code, device code, and token exchange flows, even if an earlier token or session revocation did not complete successfully.

Third-party application scopes are revalidated

Removing a user scope from a third-party application's consent configuration now affects existing grants as well as new authorization requests.

• Refresh token exchanges drop scopes that are no longer configured.
• Authorization requests resuming an existing grant fail with invalid_scope when appropriate.
• Organization token requests fail with insufficient_scope after the organizations scope is removed.
• Consent submission no longer grants a scope that was removed while the consent screen was open.

Identifier lockouts use normalized identifiers

Sentinel lockout counters now use the same normalized identifier form as account lookup:

• Email addresses are lower-cased.
• Phone numbers are canonicalized.
• Usernames are case-folded only when the tenant's username policy is case-insensitive.

This prevents alternate spellings of the same identifier from creating separate attempt buckets and weakening maxAttempts.

Manual unlock also clears equivalent spellings where they identify the same account. After upgrading, an existing lockout recorded under a non-canonical spelling may end early, but no user becomes more locked out than before.

Redirect validation

• Social landing-page redirect_to values must use http or https.
• Native callback links must use a custom application scheme.
• Stored callback links are checked again before the browser returns control to a native app.
• The unused Experience Springboard route has been removed to eliminate an untrusted redirect surface.

Bug fixes & stability

Authentication and authorization

• Revoking a user's third-party application authorization now invalidates only that application's tokens. The user's browser SSO session remains active.
• Elliptic Curve signing keys now advertise the algorithm matching their curve: P-256 uses ES256, P-384 uses ES384, and P-521 uses ES512.
• Switching from passkey sign-in to verification-code sign-in no longer prevents users from completing CAPTCHA.
• OIDC invalid_scope and insufficient_scope messages now show the rejected scope instead of raw {{error_description}} or {{scope}} placeholders.

Experience and localization

• Safari and other password managers can now suggest and save a strong password on set-password and reset-password screens using the correct account identifier.
• Accept-Language quality values with whitespace, such as en; q=0.7, are now parsed correctly. Invalid quality values fall back safely instead of producing NaN.
• Gmail custom allowlist and blocklist matching now treats gmail.com and googlemail.com as equivalent and ignores dots in the local part.
• Console now provides clearer examples, descriptions, and shorter placeholders for custom email rules.

Account Center and Management API

• Saving Account Center or sign-up settings now drops references to deleted custom profile fields instead of returning custom_profile_fields.entity_not_exists_with_names.
• Deleted fields remain removable from Console even when their permission control is Off.
• Management API relation endpoints now accept empty scope or role arrays as no-ops instead of returning a 500 error. This includes endpoints such as:
  • POST /applications/:applicationId/user-consent-scopes
  • POST /organizations/:id/users/:userId/roles
• Date validation now matches the complete input and rejects trailing characters after an otherwise valid date.

Webhook delivery

Webhook POST requests now retry up to three times when the endpoint returns an HTTP 5xx response, matching the documented delivery contract.

Because a retried event may be delivered more than once, webhook receivers should process events idempotently.

Connectors

Microsoft Azure AD

The Microsoft Azure AD connector now supports a disableEmailSync option.

By default, the connector continues to copy the Microsoft Graph mail attribute into the Logto user profile. Enable this option when the connector should authenticate the user without synchronizing that address, matching the existing control available for Azure OIDC enterprise SSO.

Self-hosting & OSS notes

• Action required — outbound request protection: If webhooks or enterprise SSO connectors intentionally access services on a private network, add the required IP addresses or CIDR ranges to SSRF_ALLOWED_ADDRESSES before upgrading:
  SSRF_ALLOWED_ADDRESSES=10.0.0.0/8,127.0.0.1
  Allowlisting only the required destinations is safer than disabling protection globally.
• Dynamic app compatibility: Configuring SSRF_ALLOWED_ADDRESSES disables CIMD so unauthenticated dynamic clients cannot use the allowlist to reach private services. Setting SSRF_PROTECTION_DISABLED=true also disables CIMD.
• Configuration compatibility: OIDC_PROVIDER_SSRF_PROTECTION_DISABLED remains supported as an alias for SSRF_PROTECTION_DISABLED. These variables apply only to self-hosted deployments.
• Script runtime limits: Custom JWT and Actions scripts must complete within 5 seconds, stay within the 128 MB worker memory budget, and return JSON-serializable values.
• Database migration required: This release ships new schema alterations and indexes. 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.

Contributors

Huge thanks to the community members whose work shipped in this release:

• @arpitjain099 - complete-string date validation (#9266)
• @shuvamk - RFC-compliant Accept-Language quality parsing (#9338)
• @darcyYe - webhook retries for HTTP 5xx responses (#9410)

For the complete list of changes, see the full changelog.

Have questions or feedback? Join us on Discord or open an issue on GitHub.

Original source

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.

Custom domain verification files

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:

• A path that is either a root-level filename with an extension (for example /verify.txt) or a path under /.well-known/.
• A content type of text/plain or application/json. JSON content is validated on save.
• Content up to 16 KB.

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.

Email access rules: allowlist and wildcard patterns

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.

Reset password magic links

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 event

Grant.LimitExceeded webhook event

When 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.

OIDC provider upgraded to node-oidc-provider v9

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:

• The revocation endpoint now rejects JWT access tokens with unsupported_token_type, instead of returning a success response without actually revoking anything as in v8.
• The RFC 8414 authorization server metadata endpoint is available at /oidc/.well-known/oauth-authorization-server.
• The redundant at_hash claim is removed from ID tokens issued at the token endpoint.
• ID tokens no longer include the optional 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.

HTTP framework upgraded to Koa 3

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.

Security and API hardening

• Internal application secrets are no longer exposed through Management APIs.
• The email blocklist policy is no longer returned in public sign-in experience responses.
• Retrieving stored third-party provider access tokens through the Account API now requires the identities user scope, matching the other social and enterprise SSO identity endpoints.
• Account API verification codes are no longer sent to blocked email addresses.
• Email and email domain validation now matches complete values and enforces stricter domain labels.

Experience, storage, and stability fixes

• When a social or SSO registration flow is rejected by email access rules, acknowledging the error now returns the user to the Logto sign-in page instead of navigating back to the external identity provider.
• MFA is now enabled automatically after a user binds a factor through the Account APIs.
• Creating a new email or SMS connector runs the insert and the cleanup of old connectors in a single database transaction. Previously a crash between the two statements could leave duplicate connectors behind.
• Redis cluster credentials are now percent-decoded, so connections succeed when the username or password contains URL-reserved characters.
• TLS is now correctly enabled for Redis cluster connections that use the rediss protocol.

Connector updates

• jose v6: The Apple, Google, OAuth, and OIDC connectors now use jose 6, which runs on the Web Crypto API instead of Node's crypto module. Token signing and ID token verification behave exactly as before.
• GitLab: Removed the unused jose dependency, so installing the connector no longer pulls in a package it never imported.
• Aliyun SMS: Hong Kong phone numbers are now treated as overseas numbers.
• Aliyun SMS authentication service (MAS): The signature is now entered as free text instead of a dropdown, so it keeps working if Aliyun rotates signatures again.

For self-hosted users

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.

Thanks to our contributors

Huge thanks to the community members whose work shipped in this release:

• @Kathircpe — Grant.LimitExceeded webhook event (#9230) and transactional passwordless connector replacement (#9277)
• @d4nyll — Redis cluster credential decoding (#9145) and rediss TLS fix (#9144)
• @sjh9714 — Aliyun SMS Hong Kong number handling (#9111)
• @CertStone — free-text Aliyun SMS MAS signature (#9228)

Get started

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.

Original source

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.

App-level access control

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.

Password expiration policies

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 gets more self-service controls

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:

• Theme, platform, and brand color are applied before hydration to reduce visual flash.
• Step-up verification is limited to user permission verification records.
• Social identities can be linked without password, email, or phone verification when the user has no legacy security verification methods.
• Console username editing now redirects to Account Center so required verification can complete.

Username and verification-code policies

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.

Safer message delivery

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.

JWT customizer and API improvements

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.
• The endpoint now returns 201 with { roleIds, addedRoleIds }, matching the user role assignment API shape.
• Organization role creation with initial scopes is now transactional, so invalid scope IDs no longer leave partially created roles behind.

Security and protocol hardening

This release includes a focused set of protocol and security fixes:

• SAML IdP auto-submit forms now escape HTML attribute values and reject non-HTTP(S) action URLs.
• samlify is upgraded to ^2.13.0 for improved XML escaping in generated SAML assertions.
• TOTP MFA verification rejects replayed codes from the same or older time-step counter.
• OIDC request bodies containing null bytes now return 400 invalid_request.
• Audit log payloads strip null bytes before insertion.
• Email subaddressing blocklist checks no longer build regular expressions from user-controlled input.
• Logto Tunnel prevents static file requests from reading outside the configured experience path.

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.

New and improved connectors

This release adds and improves several connector-related capabilities:

• New SMTP2GO email connector for sending transactional auth emails through the SMTP2GO send API.
• QQ connector support for social identity verification with stored redirect URI.
• SAML connector upgrade for samlify and its stricter return types.
• Connector Kit now exports shared SMTP mailbox parsing and formatting utilities, also used by MailJunky.

For self-hosted users

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.

Get started

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.

Original source

Logto v1.40.0 brings a time-range picker for audit logs, richer organization membership webhook payloads, big performance wins for large organizations, and several self-hosting quality-of-life improvements.

Logto v1.40.0 is a platform-hardening release. It makes audit logs practical at scale, tells you exactly what changed in organization membership webhooks, speeds up organization queries on large tenants, and removes a couple of long-standing friction points for self-hosted deployments. Three new connectors land too. Here's what's new.

Audit logs you can actually scope

Audit logs are most useful when something just happened — but until now the Console fetched an unbounded window, which got slow on tenants with very large log volumes.

This release adds a time-range picker to the audit logs page, defaulting to the last 7 days. You get preset windows (Last 1 hour, Last 24 hours, Last 7 days, Last 30 days) and a custom date range, and older logs stay reachable by simply widening the window (#8810).

Under the hood, the Management API gains start_time and end_time query parameters on GET /api/logs and GET /api/hooks/{id}/recent-logs (exclusive bounds in unix milliseconds), so you can scope log queries programmatically too (#8806). For the very largest tenants, a new enableCap=true parameter short-circuits the count query at ~10,000 rows and returns a Total-Number-Is-Capped: true header, trading an exact total for a response that won't hit statement_timeout; the Console falls back to a Prev/Next layout when the cap is reached (#8796, #8802). Default behavior without the parameter is unchanged.

Organization membership webhooks now tell you what changed

The Organization.Membership.Updated webhook used to tell you that membership changed, but not what changed. It now carries explicit delta fields — addedUserIds/removedUserIds and addedApplicationIds/removedApplicationIds — across the membership endpoints, plus addedUserIds on invitation accept and just-in-time provisioning (email-domain and enterprise SSO JIT) (#8840).

This is fully additive and non-breaking: empty deltas are omitted, and each array is capped at 5000 entries for bulk operations (reconcile via GET /organizations/:id/users or .../applications when you exceed that). See the webhook reference for the full contract. This work supersedes an earlier community proposal — credit to @chiche84 (#8752).

While we were in the sessions code, GET /api/my-account/sessions also gained an isCurrent flag on every entry, so session-management UIs can mark the "This device" row and avoid revoking the caller's own session (#8731).

Organizations that stay fast as they grow

Several changes target tenants with very large organizations:

• GET /organizations/:id/users now aggregates roles through a LATERAL subquery, so LIMIT prunes the user set before role lookups run — instead of materializing the entire members × roles join on every paginated request (#8826).
• Two new secondary indexes accelerate reverse lookups: one on organization_user_relations (tenant_id, user_id), hit on every sign-in and by the membership middleware (#8818), and one on organization_role_user_relations (tenant_id, organization_id, user_id), hit by getUserScopes and per-user role joins (#8819).
• PUT /organizations/:id/users switches to a new delta-based query that writes only the rows that actually changed, instead of rewriting every membership row on each call — and it preserves role assignments for members who survive the update (#8820).

Account Center and sign-in fixes

• Terms on sign-in-to-registration. When the agreement policy is "require checkbox agreement on registration only," signing in with an unregistered email or phone and then choosing "create a new account" now prompts the terms agreement before the account is created — matching the dedicated registration and social/SSO flows (#8835).
• Initial password setup. Users with no password, email, or phone can now set their first password through the Account API without a verification record (#8746).
• Silent re-authentication. On a user-info error — for example a stale access token after switching users in the same browser — Account Center re-authenticates with prompt=none instead of bouncing to the login screen, thanks to @taka-guevara (#8785).
• Cleaner session expiry and social callbacks. Expired Account Center sessions redirect without flashing the manual sign-in error (#8830), the social linking callback now reads connectorId correctly (#8758), and the 2-step verification toggle label is clearer (#8792).
• i18n. Corrected the Chinese translation of "Passkey" in the MFA phrases, thanks to @rotempasharel1 (#8870).

New and improved connectors

This release adds three connectors and improves several more — several of them from the community:

• MailJunky email connector for transactional auth emails, contributed by @devadarshh (#8638).
• SMSBao SMS connector for domestic SMS verification, contributed by @wintbiit (#8871).
• Aliyun SMS authentication service connector, contributed by @CertStone (#8385).
• Aliyun Direct Mail now supports configuring the Direct Mail region (#8892).
• WeCom fetches richer user profile details via additional API calls, contributed by @liyujun-dev (#8191).
• SMTP auth may now omit user and pass, so relays that authorize by source (e.g. IP/VLAN) work without forging credentials (#8888).
• Connector Kit tightened email branding URL detection to avoid false positives on dotted abbreviations, thanks to @aayushbaluni (#8747).

For self-hosted users

A couple of changes specifically smooth out OSS deployments:

Air-gapped admin setup. The install and db seed commands now accept a --dapc flag (alias --disable-admin-pwned-password-check). The admin tenant's seeded password policy enables the Have I Been Pwned breach check by default, which calls api.pwnedpasswords.com on every admin password submission — and hangs the first admin sign-up when that endpoint is unreachable. Passing --dapc seeds the policy with the breach check disabled, so admin sign-up no longer depends on outbound network access. (Credit @darcyYe, #8859)

Admin signing keys from the database. OSS deployments now read the admin tenant signing keys directly from the database, removing the extra host/DNS mappings that previously let the Logto container fetch its own admin tenant OIDC configuration through the externally configured endpoint (#8869).

Migration required. v1.40.0 ships database schema alterations (the new organization-relation indexes and additional internal columns). After pulling the new version, run the database alteration step before starting the server. See the upgrade guide.

Get started

Ready to upgrade? Check out our 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.

Original source

Logto v1.39.0 is here, bringing safer signing key rotation, smarter JWT script error handling, expanded Account Center security controls, WhatsApp connector support, and key security improvements

We’re thrilled to introduce Logto v1.39.0, a release focused on stronger operational safety, more flexible token customization, and improved end-user account security. This version adds a grace period for private signing key rotation, configurable error handling for custom JWT scripts, a new Account Center security page, WhatsApp connector support via Meta Cloud API, and several security and reliability improvements across authentication flows.

Highlights

• Private signing key rotation grace period: Logto now supports a grace period when rotating private signing keys, helping clients refresh cached JWKS without downtime.
• Custom JWT script error handling: Access token and client credentials JWT customization can now block token issuance when scripts fail.
• Account Center security page: End users can now manage social account linking, MFA, and account deletion from the Account Center.
• WhatsApp connector: A new WhatsApp SMS connector is available through the Meta Cloud API.
• Security and compatibility fixes: Forgot-password verification responses are now unified to reduce account enumeration risk, and in-app browser social / SSO redirects are more resilient.

New features & enhancements

Private signing key rotation grace period

Logto now supports a grace period during private signing key rotation.

This can be configured through:

• The PRIVATE_KEY_ROTATION_GRACE_PERIOD environment variable.
• The --gracePeriod CLI option.

During the grace period:

• The newly generated signing key is marked as Next.
• The existing signing key remains active as Current.
• Clients have time to refresh cached JWKS before the new key becomes active.

After the grace period ends:

• The new private signing key transitions to Current.
• The old signing key is marked as Previous.

This provides a smoother key rotation process and helps avoid authentication failures caused by stale JWKS caches.

Documentation: Rotate signing keys

Custom JWT script error handling

Logto now supports configurable error handling for custom JWT scripts used in access token and client credentials flows.

Included changes:

• Custom JWT scripts can now block token issuance when execution fails.
• api.denyAccess() is preserved as an access_denied response.
• Other blocking-mode script failures are returned as localized invalid_request responses.
• Console adds a dedicated Error handling tab for configuring the behavior.
• Newly created scripts default blockIssuanceOnError to enabled.
• Existing scripts without a saved value keep the legacy disabled behavior.
• Related Console guidance, phrases, schemas, and integration coverage are updated.

This helps developers choose whether token customization failures should fail open or fail closed depending on their security requirements.

Account Center security page

This release adds a new security page to the out-of-the-box Account Center.

End users can now manage account security from /account/security, including:

• Social account linking and unlinking.
• MFA 2-step verification.
• Account deletion.

Console support:

• The sign-in experience Account Center settings now expose the delete-account URL field.
• Console surfaces Account Center and social prebuilt UI entries.

WhatsApp connector via Meta Cloud API

A new WhatsApp connector is added for sending messages through the Meta Cloud API.

This enables WhatsApp-based SMS / verification-code delivery scenarios using the official Meta Cloud API integration.

Organization assignment API response bodies

Organization user and role assignment APIs now return response bodies.

Updated endpoints:

• POST /organizations/:id/users now returns { userIds: string[] }, echoing the user IDs sent in the request.
• POST /organizations/:id/users/:userId/roles now returns { organizationRoleIds: string[] }, containing the final deduplicated role IDs assigned to the user, including IDs resolved from provided role names.

Console theme token update

Console themes now include the missing --color-overlay-primary-subtle token for both light and dark modes.

Bug fixes & stability

Forgot-password verification enumeration protection

Forgot-password verification now returns a unified verification_code.code_mismatch error.

This prevents the flow from exposing whether an email or phone number exists through different error responses.

Social and SSO redirects in in-app browsers

Improved social and SSO redirect reliability in in-app browsers such as Instagram, Facebook, and LINE.

Some in-app browsers open OAuth identity provider pages in a new WebView, which can cause sessionStorage to be lost after redirecting back.

This release adds a localStorage fallback:

• Redirect state is still stored in sessionStorage.
• A fallback redirect context bundle is also stored in localStorage.
• On callback, Logto restores state from localStorage if sessionStorage is missing.
• Fallback entries are consumed on read and automatically swept after 10 minutes.
• If both storage locations are empty, the user sees an error toast.

Verification code connector request IP

Fixed an issue where the request IP was not passed to connectors when sending verification codes.

This allows connectors to receive the correct request context for verification-code delivery.

Original source

Logto v1.38.0 is here.

This release brings OAuth 2.0 Device Authorization Grant support, passkey sign-in, adaptive MFA, session and grant management, and more flexible OIDC configuration for OSS deployments.

We're excited to announce Logto v1.38.0, our March 2026 release! This update adds device flow for input-limited apps, introduces passkey sign-in and adaptive MFA improvements, and expands session, grant, and tenant-level configuration controls across Logto.

Device flow for input-limited apps

One of the biggest additions in this release is support for OAuth 2.0 Device Authorization Grant. This makes it much easier to build authentication flows for devices that do not have a full keyboard or browser experience, such as smart TVs, CLI tools, gaming consoles, and IoT devices.

With device flow, users can:

• Start sign-in on the device
• Open a verification URL on another device
• Enter a short user code
• Complete authentication there
• Return to the original device with tokens issued

We also added full Console support for device flow applications. You can now create device flow apps by selecting Input-limited app / CLI under Native apps, or by choosing Device flow as the authorization flow when creating an app manually. The application settings page also includes a built-in guide and demo to help you get started.

Passkey sign-in becomes a first-class flow

This release introduces passkey sign-in as a full authentication method in Logto.

Passkey sign-in provides a faster, passwordless experience for returning users while also improving account security. It works with familiar platform authenticators such as Face ID, Touch ID, and Windows Hello.

We added support for several passkey-based user journeys:

• A dedicated Continue with passkey button for immediate sign-in
• An identifier-first flow that prioritizes passkey verification before falling back to password or verification code
• Browser autofill support so users can pick a saved passkey directly from the identifier input
• Passkey binding during registration for new users
• Reusing an existing WebAuthn MFA credential for passkey sign-in without another registration step

For more details, check out our passkey sign-in documentation.

Adaptive MFA and better MFA guidance

This release continues our investment in modern MFA experiences with two major improvements.

Adaptive MFA

Adaptive MFA is now supported in Logto. When enabled, the sign-in flow evaluates adaptive MFA rules against the current sign-in context and requires MFA when those rules are triggered.

This also includes:

• Adaptive MFA configuration in Console
• Persisted sign-in context in interaction data
• Access to context.interaction.signInContext in custom-claims scripts
• A new PostSignInAdaptiveMfaTriggered webhook event

Optional MFA onboarding

For users who are not required to set up MFA, Logto can now show a dedicated onboarding page after credential verification, asking whether they want to enable MFA for better protection.

This is especially useful alongside passkey sign-in, where a user may want to use passkeys for sign-in without necessarily enabling them as an MFA factor at the same time.

Session and grant management across APIs and Console

This release adds a major set of account and admin controls around user sessions and authorized applications.

User session management

Logto now supports session management in both account APIs and management APIs. You can list active sessions, inspect session details, and revoke sessions with optional grant revocation behavior.

We also introduced:

• A new session permission in Account Center settings with off, readOnly, and edit options
• A new urn:logto:scope:sessions user scope for session-related account API access
• Richer session context including IP, user agent, and GEO location when available

On the Console side, user details now include an Active sessions section and a dedicated session details page with revoke support.

Authorized application grant management

Logto now supports listing and revoking user application grants in both the account and management APIs.

This release also adds an Authorized third-party apps section on the user details page in Console. Admins can now see active third-party authorizations, review metadata such as app name and creation time, and revoke access directly from the UI.

App-level concurrent device limits

Applications can now define a maxAllowedGrants value in customClientMetadata to limit how many active grants a user can keep for a specific app. Once the configured limit is exceeded, Logto automatically revokes the oldest grants.

Console also includes a new Concurrent device limit section in application details so this can be configured visually.

More OSS controls for OIDC settings

For OSS users, this release makes OIDC settings more configurable and easier to manage.

You can now define oidc.session.ttl in logto-config to customize the OIDC provider session TTL in seconds. If unset, the default remains 14 days.

We also added:

• GET /api/configs/oidc/session
• PATCH /api/configs/oidc/session

On the Console side, OSS now gets a new Tenant -> Settings page, with an OIDC settings tab that replaces the old Signing keys page. The new page also includes a Session maximum time to live field for configuring session TTL in days.

If you are running OSS, remember to restart the service after config changes so the new OIDC settings are loaded. If you want config updates to take effect automatically, consider enabling central Redis cache.

Account Center improvements

The out-of-the-box Account Center also gets several useful upgrades in this release.

Users can now:

• Replace their authenticator app through a dedicated /authenticator-app/replace route
• Use the identifier URL parameter to pre-fill identifier fields
• Override the built-in Account Center language with the ui_locales URL parameter

We also improved password forms for better browser autofill and password manager compatibility.

Developer-focused API improvements

For teams migrating users into Logto, the GET /users and GET /users/:userId endpoints now support an includePasswordHash query parameter. When enabled, the response includes passwordDigest and passwordAlgorithm, which can help with migration workflows that need raw password hash data.

We also added support for access token exchange in service-to-service delegation scenarios. Logto can now exchange opaque or JWT access tokens for new access tokens with different audiences using the standard urn:ietf:params:oauth:token-type:access_token token type.

Bug fixes

This release also includes several stability and compatibility improvements:

• MFA verification routes for TOTP, WebAuthn, and backup codes now report activity to Sentinel, making repeated failures easier to detect and isolate.
• OIDC adapter queries for findByUid and findByUserCode now use literal JSONB keys so expression indexes can work better under prepared generic plans.
• Postgres pool initialization now retries on transient startup connection errors.
• Legacy password verification now supports hex:-prefixed PBKDF2 salt values during user import.
• Token exchange performance is improved by caching minimal OIDC resource lookups and pre-generating grant IDs during token issuance.
• Twilio SMS To formatting is now normalized for non-E.164 numbers by ensuring a leading +.

Breaking changes

This release includes a connector toolkit breaking change.

The long-deprecated mockSmsVerificationCodeFileName export has been removed from @logto/connector-kit.

We also updated the file paths used by mock connectors to store sent message records:

• /tmp/logto_mock_email_record.txt -> /tmp/logto/mock_email_record.txt
• /tmp/logto_mock_sms_record.txt -> /tmp/logto/mock_sms_record.txt

If your local or Docker-based workflows depend on the old paths, you will need to update them.

New contributors

Thanks to our new contributors for helping improve Logto:

• @taka-guevara made their first contribution in #8555
• @synchrone made their first contribution in #8504
• @ppotaczek and @leoshusar made their first contribution in #8526

Get started

Ready to upgrade? Check out our 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.

Original source

Logto v1.37.0 is here with a built-in Account Center app, richer JWT customization using application context, and configurable ID token claims. It also fixes custom-domain redirect issues and improves sign-up and social linking flow stability.

New features & enhancements

Built-in Account Center app

This release introduces the Account Center single-page app as a built-in Logto application for end users:

• Supports profile updates for primary email, phone, username, and password, with verification flows.
• Supports MFA management for TOTP, backup codes (download/regenerate), and passkeys (WebAuthn), including rename and delete actions.
• Sensitive operations are gated by password/email/phone verification and include dedicated success screens.

Documentation:

Account settings by Account API

Application context in JWT Customizer

Application context (for example app name, description, and custom data) is now available in JWT customizer scripts for:

• Access token
• Client credentials token

This enables app-aware JWT claim customization.

ID token claims configuration

You can now configure additional claims included in ID tokens via Console or Management API:

• custom_data
• identities
• roles
• organizations
• organization_roles

Bug fixes & stability

Built-in app redirect URI fix for custom domains

Fixed an invalid_redirect_uri issue for built-in Account Center and Demo app under custom-domain requests.

• Root cause: Built-in client metadata was generated from default tenant URLs only, while runtime redirect_uri could be based on a custom domain.
• Fix: getTenantUrls now accepts an optional runtime endpoint. Built-in metadata generation for Account Center and Demo app now includes envSet.endpoint, so redirect/logout URIs automatically include the active custom domain.

"Tell us about yourself" section visibility fix

Fixed an issue where the "Tell us about yourself" section did not appear during sign-up when only optional custom profile fields were configured.

• Previously only required fields were checked, so optional-only setups were skipped.
• The check now includes optional fields and whether the extra profile form has been submitted, ensuring expected visibility.

Social link flow context preservation fix

Fixed a broken social account linking flow in this scenario:

• username + email are both enabled as required sign-up identifiers.
• "Require users to provide missing sign-up identifiers for social sign-in" is enabled.
• The social IdP returns no verified email.
• The user fulfills username, then enters an already-registered email.

Previously, the link_social parameter was not propagated after username fulfillment, causing link context to be lost before email verification. The flow now appends and preserves link_social so the expected link-and-sign-in behavior works correctly.

Original source

Logto v1.36 brings wildcard redirect URI support for preview deployments, app-level token exchange control, trust unverified email option for OIDC connectors, and the ability to skip identifier collection for social sign-in.

Logto v1.36 is here. This release brings wildcard redirect URI support, app-level token exchange control, and the ability to trust unverified emails in OIDC connectors.

Wildcard redirect URIs

Thanks to community contributor @Arochka, you can now use wildcard patterns (*) in redirect URIs. This is especially useful for dynamic environments like preview deployments where URLs are generated on the fly.

Rules for web applications:

• Wildcards work in the hostname and pathname of http/https URIs
• Wildcards are not allowed in scheme, port, query, or hash
• Hostname patterns must include at least one dot to prevent overly broad matches

Token exchange with app-level control

Token exchange is now available for machine-to-machine applications, and you have fine-grained control over which apps can use it.

• New allowTokenExchange setting in application configuration
• New apps have token exchange disabled by default
• Existing first-party apps (Traditional, Native, SPA) keep it enabled for backward compatibility
• Third-party apps cannot use token exchange
• Console shows a risk warning when enabling for public clients

Trust unverified email for OIDC connectors

Some identity providers don't return email_verified or return it as false even when the email is valid. You can now configure OIDC social connectors and enterprise SSO connectors to sync emails regardless of verification status.

Enable trustUnverifiedEmail in your connector config (default is false). This option is available in the Admin Console for OIDC and Azure AD SSO connectors.

Skip identifier collection for social sign-in

Apple App Store guidelines require that "Sign in with Apple" doesn't ask for additional information beyond what Apple provides. To help with this, we've added a new option to skip mandatory identifier collection during social sign-in.

Find the "Require users to provide missing sign-up identifier" checkbox in the Social sign-in section of your sign-in experience settings.

API improvements

User role APIs now return results

• POST /users/:userId/roles returns { roleIds, addedRoleIds } showing which roles were newly assigned
• PUT /users/:userId/roles returns { roleIds } confirming the final state

New createApiClient function in @logto/api

Create a type-safe API client with your own token retrieval logic for custom authentication flows.

Bug fixes

• Postgres timeout: Set DATABASE_STATEMENT_TIMEOUT=DISABLE_TIMEOUT for PgBouncer/RDS Proxy compatibility
• Enterprise SSO error: Fixed error code when SSO account doesn't exist
• JIT email domains: Removed pagination limit so all domains show in Console
• Direct sign-in: Fixed repeated auto sign-in requests
• Audit log filters: Fixed typos causing empty filter results

Original source

Logto v1.35 is here. This release adds reCAPTCHA domain customization and checkbox mode for Enterprise, expands third-party app support to SPA and Native applications, and includes client IP tracking for passwordless connectors.

We're excited to announce Logto v1.35.0, our December 2025 release! This update brings enhanced reCAPTCHA customization options, expanded support for third-party applications, and improved security features for passwordless authentication.

reCAPTCHA Gets More Flexible

Use reCAPTCHA Anywhere with Domain Customization

One of the most requested features has been the ability to use reCAPTCHA in regions where Google's default domain may be inaccessible. With v1.35.0, you can now customize the reCAPTCHA domain to use alternatives like recaptcha.net, ensuring your bot protection works seamlessly for users worldwide.

Choose Your Verification Style with Checkbox Mode

reCAPTCHA Enterprise users now have a choice between two verification modes:

• Invisible mode: The default score-based verification that runs silently in the background, providing a frictionless user experience while still protecting against bots.
• Checkbox mode: The classic "I'm not a robot" widget that many users are familiar with. This mode provides explicit user interaction and can be useful when you want users to consciously acknowledge the verification step.

Simply ensure your verification mode matches your reCAPTCHA key type configured in Google Cloud Console, and you're ready to go.

Third-party Apps: Now for SPA and Native Too

Previously, only traditional web applications could be designated as third-party apps in Logto. This release removes that limitation, allowing you to create third-party single-page applications (SPA) and native applications.

This enhancement opens up more flexible OAuth/OIDC integration scenarios, whether you're building a partner ecosystem, enabling third-party integrations, or managing multiple client applications with different trust levels.

Enhanced Security for Passwordless Authentication

Client IP Tracking

For organizations that need additional security controls around passwordless authentication, we've added client IP address tracking to the connector message payload. The SendMessageData type now includes an optional ip field that HTTP email and SMS connectors can utilize for:

• Rate limiting: Prevent abuse by limiting requests from specific IP addresses
• Fraud detection: Identify suspicious patterns based on IP geolocation or reputation
• Audit logging: Maintain comprehensive logs for security compliance

Smarter Email/SMS Template Handling

We've improved the template fallback logic for email and SMS connectors. If a usage-specific template isn't found, the system now gracefully falls back to the generic template. This includes checking the generic template with the default locale when locale-specific templates are unavailable, ensuring your users always receive properly formatted messages.

Bug Fixes

SAML Integration Improvements

• Extended relay state support: The relay state column now supports up to 512 characters (previously 256), fixing integration issues with service providers like Firebase that generate longer relay state values.
• Better error messages: SAML authentication flow APIs now provide more straightforward error messages, making troubleshooting easier.

API Parameter Fix

Fixed a parameter naming issue in the SAML app creation API that could cause filter and paywall calculation errors.

Get Started

Ready to upgrade? Check out our 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.

Original source

Logto v1.34 is here. This release introduces isolated cross-app authentication, a new Identifier.Lockout webhook event, and fixes to ensure refresh tokens correctly honor the full 180-day TTL.

Highlights

• Cross-app authentication stability: Authentication callbacks are now isolated per application within the same browser session, eliminating interference caused by shared _interaction cookies.
• New webhook event Identifier.Lockout: A new webhook event Identifier.Lockout is introduced, triggered when a user is locked out after repeated failed sign-in attempts.
• Improved refresh token reliability: Refresh tokens now correctly honor the configured 180-day TTL, resolving an issue where they previously expired after 14 days.

New features & enhancements

Cross-app authentication

Multiple applications can now initiate authentication in the same browser session without affecting each other.

• _interaction cookie now stores a structured mapping { [appId]: [interactionId] }.
• appId is propagated via URL parameters or headers to maintain isolation.
• Includes fallback logic for backward compatibility.

Webhooks

New webhook event: Identifier.Lockout

• Triggered when a user is locked out due to repeated failed sign-in attempts, enhancing security observability and automation.

Bug fixes & stability

Refresh token TTL fix

Addressed an issue where refresh tokens expired after 14 days due to an internal provider grant TTL cap.

• TTL now correctly aligns with the configured 180-day lifespan.
• Supports refresh token validity up to 180 days as intended.

Correct email verification code template selection during multi-step sign-up

Fixed a bug where the system incorrectly switched to MFA binding templates during multi-step sign-up flows.

• Sign-up templates are now selected correctly when email/phone identifiers are part of the ongoing sign-up process.

Case-insensitive SSO connectors domain matching

SSO connector domain matching is now case-insensitive, improving reliability during sign-in flows.

• SSO connector domains are now normalized to lowercase upon insertion.
• Prevents duplicate domain entries and ensures proper connector lookup.
• Domain matching during sign-in is now robustly case-insensitive.

Original source

We’ve just brought v1.33, bringing Account Center configuration, MFA skip controls API, and a few handy improvements.

Highlights

• Account Center Configuration: You can now fully configure the Account Center directly within the Logto Console.
• MFA Skip Controls API: New API endpoints are introduced to manage Multi-Factor Authentication (MFA) skip controls for a more flexible user experience.
• Experience Compatibility Fix: Resolved a critical bug that prevented Logto Experience from working on older Android and some browser versions.

New Features & Enhancements

Logto Console

• Add Account Center Config Page: You can now configure the account center in the Logto Console.
• Keep the “Third-party applications” tab permanently visible on the Applications page.

Core & API Changes

• Add API for MFA Skip Controls: Expose logto_config endpoints in account and management APIs for managing MFA skip controls:
  • /api/my-account/logto-configs
  • /api/admin/users/:userId/logto-configs
• Append applicationId to the Experience API audit logs for enhanced traceability.
• Add Body-Based Personal Access Token APIs: Introduce PATCH/POST endpoints that accept token names in the request body to support special characters while keeping path-based routes for compatibility:
  • PATCH /api/users/{userId}/personal-access-tokens
  • POST /api/users/{userId}/personal-access-tokens/delete

Bug Fixes & Stability

Logto Experience

• Fix an issue that prevents Logto Experience from working in Android 11 and some older browser versions. The issue was introduced by the usage of the ||= operator, which is not supported in these older environments.
• Fix the country code dropdown menu position on desktop. This includes fixing the initial position calculation and adding a max dropdown menu top position to prevent it from going off-screen on smaller displays.

Core Logic

• Fix a bug that the locale parameter used in email templates does not respect the user custom languages.
• Remove deprecated interaction API endpoints from OpenAPI swagger documentation, as they have been replaced by the Experience API endpoints.

Original source

We’ve just rolled out v1.32, bringing new MFA options, better localization support, and a few handy improvements.

Email and phone MFA

You can now let users secure their accounts with either email or phone-based MFA, verified through OTP codes.

• New MFA factors: email verification code and SMS verification code.
• Bind these factors during registration or first sign-in when MFA is required.
• Use dedicated verification pages for sign-ins.
• Console updates: configure factors, see guidance, and get conflict warnings.
• Forgot password flows can now be customized in the Sign-in Experience.
  👉 Learn more in the docs

OIDC ui_locales support

Logto now supports the standard OIDC ui_locales authentication parameter. This lets you control the language of authentication pages at runtime.

• The UI language is chosen based on the first supported tag in ui_locales.
• Verification emails triggered during sign-in follow the same localization.
• The value is also available in email templates as uiLocales.
  👉 More details here

Other improvements

• Twilio connector: option to disable built-in risk checks.
• X connector: add the users.email scope to sync email addresses.

Bug fixes

• WebAuthn rpId now matches the request domain in the Account API, consistent with the sign-in experience (including custom domains).

Original source

🎉 Introducing our August release: Collect user profile at signup, PBKDF2 legacy password support, Thai localization, and a new HTTP SMS connector!

Collect user profile at registration

You can now collect user profile information on the last step of the end-user registration flow.
This lets you extend the basic sign-up form with built-in or custom fields so you can immediately capture attributes you need (e.g. name, gender, birthdate, address, custom preferences) before the new user finishes onboarding.

How to enable

1. Go to Console > Sign-in Experience > Collect user profile.
2. Add fields:

• Use built-in basics (Name, Gender, Birthdate, Address, …), or
• Create custom fields (choose type, label, validation rules, required, etc.).

1. Drag & drop to reorder; the order matches the rendered form.
2. Preview or test by signing up a new user (e.g. in the demo app). A "Tell us about yourself" step appears.
3. Registration completes only after all required fields are filled.

Refer to the documentation for more details.

PBKDF2 support for legacy password verification

We added PBKDF2 (Password-Based Key Derivation Function 2) support to legacy password verification. This improves compatibility when migrating users whose passwords were originally hashed using PBKDF2. (Credit @karerckor)

Example payload for a migrated user:

{
"username": "john_doe",
"primaryEmail": "[email protected]",
"passwordAlgorithm": "Legacy",
"passwordDigest": "[\"pbkdf2\", [\"mySalt123\", \"1000\", \"20\", \"sha512\", \"@\"], \"c465f66c6ac481a7a17e9ed5b4e2e7e7288d892f12bf1c95c140901e9a70436e\"]"
}

Arguments inside the PBKDF2 tuple:

• salt: user-defined salt value
• iterations: number of iterations (e.g. 1000)
• keylen: derived key length (e.g. 20)
• digest: hash algorithm (e.g. sha512)
• @: placeholder for the input password

Refer to the documentation for more details.

New HTTP SMS connector

A new generic HTTP SMS connector is introduced (@logto/connector-http-sms). It allows sending SMS messages via any provider that exposes an HTTP-based API by configuring request method, URL, headers, body mapping, and success criteria. (Credit @michakfromparis)

Use it when a dedicated built-in SMS connector is not yet available for your provider.

Thai language support

Added Thai translations for both Logto Console and the sign-in experience. This improves localization coverage for Thai-speaking users.

Security updates and vulnerability fixes

New Contributors

• @karerckor made their first contribution in https://github.com/logto-io/logto/pull/7585
• @michakfromparis made their first contribution in https://github.com/logto-io/logto/pull/7510
• @hussamelvani made their first contribution in https://github.com/logto-io/logto/pull/7721

Original source

🎉 Introducing our July release: Logto API SDK, Secret vault for federated token storage, manage TOTP and Backup Codes via Account API, and more!

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Logto API SDK

A TypeScript SDK for interacting with Logto's Management API using client credentials authentication.

How it works:

1. Create a machine-to-machine application in the Logto Console.
2. Grant the application access to the Management API.
3. Install the SDK via npm:

npm install @logto/api

1. Use createManagementApi() to create a typed Management API client with your application's credentials.

Highlights:

• Automatically handles OAuth token authentication and renewal.
• Supports both Logto Cloud and self-hosted instances.
• Simplifies integration with Logto's Management API, letting you focus on building features instead of handling low-level API requests.

Secret vault

The Secret vault is a secure storage solution in Logto for managing sensitive user data, including access tokens, API keys, passcodes, and other confidential information. These secrets are typically used to access third-party services on behalf of users, making secure storage critical.

Federated Token Storage Support

Token storage is now supported for both social and enterprise SSO connectors. When enabled, Logto stores the token set issued by the identity provider after successful authentication. Applications can then retrieve the access token later—without requiring the user to reauthenticate—to call third-party APIs.

Supported connectors:

• Social connectors: GitHub, Google, Facebook, Standard OAuth 2.0, and Standard OIDC
• Enterprise SSO connectors: All OIDC-based SSO connectors

How it works:

1. Enable token storage for social and enterprise SSO connectors in the Logto Console or via the Logto Management API.
2. Once enabled, Logto automatically stores the token set issued by the provider after a successful user authentication.
3. Retrieve the stored token through the Account API when needed.

For more details, see the Secret vault documentation.

For OSS users: To enable the Secret vault feature, you must set the SECRET_VAULT_KEK environment variable to a valid base64-encoded secret key. This key is used to encrypt and decrypt the secrets stored in the vault. For more information, refer to the configuration variables documentation.

Add TOTP and Backup Codes via Account API

Users can now add TOTP and backup codes via the Account API.

• POST /api/my-account/mfa-verifications/totp-secret/generate: Generate a TOTP secret.
• POST /api/my-account/mfa-verifications/backup-codes/generate: Generate backup codes.
• POST /api/my-account/mfa-verifications: Add a TOTP or backup code using the generated secret or codes.
• GET /api/my-account/mfa-verifications/backup-codes: Retrieve backup codes.

Other Improvements

• Social connectors: Added support for providing a custom scope parameter when generating the authorization URL for social connectors. This allows you to request additional permissions from the social provider when calling the Logto social verification endpoint. If the scope is provided, it will be used in the authorization request; otherwise, the default scope configured in the connector settings will be used.
• Console: To better support the new Secret vault feature, we have refactored the layout of the user details page. User social and enterprise SSO identities are now organized into a new Connection section. This section lists all of a user’s linked connections, showing third-party identity information and token storage status (if applicable). A detailed user identity page is also available for each connection, providing more information about the linked identity and its associated tokens.

Bug Fixes

Tenant-aware foreign key constraint for organization_user_relations table

Problem

Developers could mistakenly assign a user_id from another tenant to an organization, causing 500 errors on organization user API endpoints. The original organization_user_relations table only had a foreign key constraint on users (id), allowing any existing user ID to be assigned regardless of tenant isolation.

Root Cause

Logto applies Row Level Security (RLS) on all tables to isolate tenant data access. When joining the users table with organization_user_relations, the actual user data becomes inaccessible to the current tenant due to RLS restrictions, causing user data to return null and triggering 500 server errors.

Solution

A composite foreign key constraint (tenant_id, user_id) referencing users (tenant_id, id) was added to ensure the organization-user relation's tenant ID matches the user's tenant ID. This enforces proper tenant isolation at the database level.

Original source

🎉 Introducing our June release: Account API for Passkeys, access user interaction details in custom JWT, and more updates!

Account API for WebAuthn (passkeys)

You can now manage WebAuthn passkeys in Account API, including:

1. Binding a WebAuthn passkey to the user's account through your website.
2. Manage the passkeys in the user's account.

We have implemented Related Origin Requests so that you can manage the WebAuthn passkeys on your website which has a different domain from the Logto's sign-in page.

To learn more, check out the documentation.

Access user interaction details in custom JWT

User interaction data is now accessible through the context.interaction when generating custom token claims:

Property | Description | Type
interactionEvent | The interaction event of the current user interaction | SignIn or Register
userId | The user id of the current user interaction | string
verificationRecords | A list of verification records submitted by the user to identify and verify their identity during interactions. | VerificationRecord[]

Example Use Case:

Read the verification records from the interaction context. If an Enterprise SSO verification record is present, include the corresponding user profile from the Enterprise SSO identities as additional token claims.

See custom token claims context for more details.

Improvements

• Updated timestamp tracking for SSO: Added updated_at field to user_sso_identities table
• Changed user password digest length to 256, supporting Legacy hashing algorithm such as SHA512
• Mask TOTP secret from audit log
• Support flexible size in Turnstile widget, allowing the widget to scale responsively and fill the available space.

Bug fixes

• Fixed SAML application callback API to properly handle RelayState parameter in authentication responses
• Made access_token optional for Azure OIDC SSO connector, previously, the Azure OIDC connector strictly required an access token in the token response, which caused issues with Azure B2C applications that only return ID tokens.
• Fixed potential WebAuthn registration errors by specifying the displayName. For example, when using Chrome on Windows 11 with the "Use other devices" option (scanning QR code), an empty displayName will cause the registration to fail.
• Fixed an issue where the payment page could not open in iOS Safari.

Original source