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 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.
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:
POST /api/hooks/:id/test.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.
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:
at+jwt type header.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 applications can no longer mutate account data through the Account API or Verification API. Such requests now return:
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/grantsGET /api/my-account/sessionsGET /api/my-account/mfa-verifications/backup-codesToken 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.
Removing a user scope from a third-party application's consent configuration now affects existing grants as well as new authorization requests.
invalid_scope when appropriate.insufficient_scope after the organizations scope is removed.Sentinel lockout counters now use the same normalized identifier form as account lookup:
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_to values must use http or https.ES256, P-384 uses ES384, and P-521 uses ES512.invalid_scope and insufficient_scope messages now show the rejected scope instead of raw {{error_description}} or {{scope}} placeholders.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.com and googlemail.com as equivalent and ignores dots in the local part.custom_profile_fields.entity_not_exists_with_names.POST /applications/:applicationId/user-consent-scopesPOST /organizations/:id/users/:userId/rolesWebhook 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.
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.
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:
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.
Huge thanks to the community members whose work shipped in this release:
Accept-Language quality parsing (#9338)For the complete list of changes, see the full changelog.
Have questions or feedback? Join us on Discord or open an issue on GitHub.