Patch Changes

This is a patch release to fix a missing version bump for @logto/core-kit.

In v1.37.0, extended ID token claims exports (extendedIdTokenClaims, ExtendedIdTokenClaim, extendedIdTokenClaimsByScope) were added to @logto/core-kit (#8317), but the changeset was missing, causing @logto/core-kit not to be bumped. This resulted in downstream packages (@logto/schemas, @logto/console) referencing exports that didn't exist in the published version.

@logto/[email protected]

• Add extended id token claims exports

Highlights

• Built-in Account Center app is now available: A ready-to-use single-page account center experience for end users.
• JWT Customizer enhancement: Application context is now available in custom scripts for both access tokens and client credentials tokens.
• Configurable ID token claims: Additional ID token claims can now be configured via Console or Management API.

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: https://docs.logto.io/end-user-flows/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.

New Contributors

• @Fatty911 made first contribution in #8333

Full Changelog: v1.36.0...v1.37.0

Highlights

• Wildcard redirect URIs: Support wildcard patterns (*) in redirect URIs for dynamic environments like preview deployments, making development workflows easier. (Thanks @Arochka!)
• Token exchange app-level control: Fine-grained control over token exchange grant type per application, with M2M apps now supporting this feature.
• Trust unverified email for SSO: OIDC social connectors and enterprise SSO connectors can now sync emails even when email_verified is missing or false.

New features & enhancements

Wildcard patterns in redirect URIs

Added support for wildcard patterns (*) in redirect URIs to better support dynamic environments like preview deployments. (Contributed by @Arochka in #8094)

Rules (web only):

• Wildcards are allowed for http/https redirect URIs in the hostname and/or pathname
• Wildcards are rejected in scheme, port, query, and hash
• Hostname wildcard patterns must contain at least one dot to avoid overly broad patterns

Token exchange grant type with app-level control

• Add allowTokenExchange field to customClientMetadata to control whether an application can initiate token exchange requests
• Machine-to-machine applications now support token exchange
• All new applications will have token exchange disabled by default; enable it in application settings
• For backward compatibility, existing first-party Traditional, Native, and SPA applications will have this enabled
• Third-party applications are not allowed to use token exchange
• Added UI toggle in Console with risk warning for public clients (SPA / native application)

Trust unverified email for OIDC connectors

• Add trustUnverifiedEmail to the OIDC social connector config (default false) to allow syncing emails when email_verified is missing or false
• Apply the setting in core OIDC/Azure OIDC SSO connectors and expose it in the Admin Console

Skip required identifiers for social sign-in

A new option skipRequiredIdentifiers is available for social sign-in and sign-up flows. When enabled, users can bypass the mandatory identifier collection step during social sign-in and sign-up.

This is particularly useful for iOS apps where Apple App Store guidelines mandate that social sign-in options like "Sign in with Apple" should not require additional information collection beyond what is provided by the social IdP.

In the Logto Console, this option is represented as a checkbox labeled "Require users to provide missing sign-up identifier" under the "Social sign-in" section.

User role API improvements

• POST /users/:userId/roles now returns { roleIds: string[]; addedRoleIds: string[] } where roleIds echoes the requested IDs, and addedRoleIds includes only the IDs that were newly created
• PUT /users/:userId/roles now returns { roleIds: string[] } to confirm the final assigned roles

@logto/api SDK enhancement

Added createApiClient function for custom token authentication. This new function allows you to create a type-safe API client with your own token retrieval logic, useful for scenarios like custom authentication flows.

Bug fixes & stability

Postgres statement timeout configuration

Allow disabling Postgres statement_timeout for PgBouncer/RDS Proxy compatibility:

• Set DATABASE_STATEMENT_TIMEOUT=DISABLE_TIMEOUT to omit the startup parameter

Enterprise SSO error code fix

Fixed the enterprise SSO account not exist error code to use a specific one instead of the generic social account error.

JIT email domains pagination fix

Removed default pagination from GET /organizations/:id/jit/email-domains to ensure all JIT email domains are returned in the Console's Organization details page.

Direct sign-in stability

Prevented repeated auto sign-in requests on direct sign-in page that could cause unexpected behavior in certain scenarios.

Console audit log fixes

• Removed deprecated interaction log events from the Console audit log filter menu
• Fixed dropdown event key typo that caused empty filter results for several events

Highlights

• reCAPTCHA domain customization: You can now customize the domain for reCAPTCHA, enabling usage with alternative domains like recaptcha.net for regions where the default domain may be blocked.
• reCAPTCHA Enterprise checkbox mode: Choose between invisible score-based verification or the classic "I'm not a robot" checkbox widget.
• Third-party SPA & Native apps: Previously limited to traditional web apps, you can now create third-party single-page applications (SPA) and native applications for more flexible OAuth/OIDC integration scenarios.

New features & enhancements

reCAPTCHA improvements

Domain customization

You can now customize the domain for reCAPTCHA. This is particularly useful for users in regions where the default google.com/recaptcha domain may be inaccessible, allowing them to use alternatives like recaptcha.net.

Enterprise checkbox mode

You can now choose between two verification modes for reCAPTCHA Enterprise:

• Invisible: Score-based verification that runs automatically in the background (default)
• Checkbox: Displays the "I'm not a robot" widget for user interaction

Note: The verification mode must match your reCAPTCHA key type configured in Google Cloud Console.

Third-party SPA & Native applications

Previously, only traditional web applications could be marked as third-party apps. Now you can also create third-party single-page applications (SPA) and native applications, enabling more flexible OAuth/OIDC integration scenarios.

Client IP in passwordless connector payload

The SendMessageData type now includes an optional ip field that contains the client IP address of the user who triggered the message. This can be used by HTTP email/SMS connectors for:

• Rate limiting
• Fraud detection
• Logging purposes

Email/SMS template fallback

Email and SMS connectors now fall back to TemplateType.Generic if a usage-specific template is not found. Additionally, the email template retrieval logic will also attempt to retrieve the generic template with default locale if both the locale-specific and fallback templates are unavailable.

Bug fixes & stability

SAML relay state length fix

The data type of the relay_state column in the saml_application_sessions table has been changed from varchar(256) to varchar(512) to accommodate longer Relay State values. This fix enables Firebase integration with Logto as a Service Provider, which previously failed due to relay state length constraints (approximately 300-400 characters).

Additionally, error handling logic in SAML authentication flow APIs has been improved to provide more straightforward error messages.

SAML app creation API parameter fix

Fixed the API parameter naming from "type" to "types" for SAML app creation, ensuring the filter works correctly and paywall calculations are accurate.

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

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.

Email and phone MFA

You can now let users choose either email or phone number for MFA, and verify them with OTP codes.

• Add two new MFA factors: Email verification code and SMS (phone) verification code.
• Support binding these factors during registration or first sign-in when MFA is required.
• Support verifying these factors on subsequent sign-ins with dedicated MFA verification pages.
• Update Console to configure these factors and surface guidance/conflict warnings.
• Support customizing forgot password methods in Sign-in Experience (related).

To learn more about this feature, please refer to the documentation: https://docs.logto.io/end-user-flows/mfa

Support OIDC standard authentication parameter ui_locales

We are now supporting the standard OIDC ui_locales auth parameter to customize the language of the authentication pages. You can pass the ui_locales parameter in the signIn method via the extraParams option in all Logto SDKs.

What it does

• Determines the UI language of the Logto-hosted sign-in experience at runtime. Logto picks the first language tag in ui_locales that is supported in your tenant's language library.
• Affects email localization for messages triggered by the interaction (e.g., verification code emails).
• Exposes the original value to email templates as a variable uiLocales, allowing you to include it in the email subject/content if needed.

Example

If you want to display the sign-in page in French (Canada), you can do it like this:

await logtoClient.signIn({
  redirectUri: "https://your.app/callback",
  extraParams: {
    ui_locales: "fr-CA fr en",
  },
});

Refer to the documentation for more details.

Support config Twilio risk control

You can now disable Twilio's built-in risk check by setting the "Disable risk check" option in the connector configuration.

X connector email address syncing

You can now add the users.email scope to sync users' email addresses from X accounts.

Bug fixes

• Bind WebAuthn rpId to request domain for account api: The rpId now matches the domain you use to access the API (including custom domains), consistent with the sign-in experience.

Full Changelog: v1.31.1...v1.32.0

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.).
3. Drag & drop to reorder; the order matches the rendered form.
4. Preview or test by signing up a new user (e.g. in the demo app). A "Tell us about yourself" step appears.
5. 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 #7585
• @michakfromparis made their first contribution in #7510
• @hussamelvani made their first contribution in #7721

Full Changelog: v1.30.1...v1.31.0

Logto API SDK

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

1. Create a machine-to-machine application in your Logto Console.
2. Grant the application access to the Management API.
3. Install the SDK via npm: npm install @logto/api
4. Use createManagementApi() to create a typed Management API client with your application's credentials.

This SDK simplifies the process of integrating with Logto's Management API, allowing developers to focus on building features rather than handling API requests and responses manually.

• Handles OAuth token authentication and renewal automatically.
• Supports both Logto Cloud and self-hosted instances.

Secret Vault

The Secret Vault is designed to securely store sensitive user data—such as 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 essential.

With this release, federated token set storage support is added to both social and enterprise SSO connectors. When enabled, Logto securely stores the token set issued by the provider after a successful user authentication. Applications can then retrieve the access token later to access third-party APIs without requiring the user to reauthenticate.

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. After the token set is stored, you can retrieve the access token via the Logto Account API for the user. This allows your application to access third-party APIs without requiring the user to reauthenticate.

For more details, see the Secret Vault 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.

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.

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.

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:

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.

const { interaction } = context;
const verifications = interaction?.verificationRecords || [];

const ssoVerification = verifications.find(
  (record) => record.type === "EnterpriseSso",
);

if (ssoVerification) {
  return {
    enterpriseSsoIdentityId:
      enterpriseSsoVerification?.enterpriseSsoUserInfo?.id,
    familyName: enterpriseSsoVerification?.enterpriseSsoUserInfo?.familyName,
  };
}

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. Contributed by @GeisonPiegas

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.