v1.38.0

Highlights

• Device flow support: Logto now supports OAuth 2.0 Device Authorization Grant for smart TVs, CLI tools, IoT devices, and other input-limited apps.
• Passkey sign-in: A full passkey-first authentication experience is now available, including button-based, identifier-first, and autofill-assisted flows.
• Adaptive MFA and optional MFA onboarding: MFA can now be triggered based on sign-in context, and users can be prompted to enable MFA after sign-in.
• Session and grant management: This release adds user session management, authorized app management, and app-level concurrent grant limits across APIs and Console.
• More OSS operator controls: OIDC session TTL is now configurable, and tenant-level OIDC settings are now exposed in Console.

New features & enhancements

OAuth 2.0 Device Authorization Grant

Logto now supports OAuth 2.0 Device Authorization Grant, allowing users to sign in on input-limited devices such as smart TVs, CLI tools, IoT gadgets, and gaming consoles by completing authentication on another device.

Included in this release:

• Full protocol support in core and schemas.
• Device flow support in the sign-in experience.
• Device flow support in Console.
• Device-flow-specific phrases and built-in demo support.
• A device-flow-specific guide in the application settings page.

Console now supports creating a device flow application by:

• Selecting Input-limited app / CLI under the Native framework list.
• Creating an app without framework and choosing Device flow as the authorization flow.
• Creating a third-party Native app and choosing Device flow as the authorization flow.

Passkey sign-in

This release introduces passkey sign-in as a first-class authentication method.

Included capabilities:

• A passwordless sign-in experience using platform authenticators such as Face ID, Touch ID, and Windows Hello.
• Prompting new users to bind a passkey during registration.
• Guiding existing users to bind a passkey in a later sign-in flow.
• Reusing an existing WebAuthn MFA credential for passkey sign-in without an extra registration step.

Supported user journeys:

1. Passkey sign-in button: Users can click Continue with passkey to trigger the browser passkey chooser immediately.
2. Identifier-first flow: Users first enter an identifier, then are prompted to Verify via passkey before falling back to password or verification code.
3. Allow autofill: Supported browsers can suggest saved passkeys directly from the identifier input.

Documentation: https://docs.logto.io/end-user-flows/sign-up-and-sign-in/passkey-sign-in

Adaptive MFA

Logto now supports adaptive MFA.

Included changes:

• Console always exposes the adaptive MFA option on the MFA settings page.
• adaptiveMfa is stored in the sign-in experience payload.
• The sign-in flow evaluates adaptive MFA rules against the current sign-in context.
• MFA verification is required when adaptive rules are triggered.
• The sign-in context is consistently persisted into interaction data, so custom-claims scripts can read it from context.interaction.signInContext.
• A new PostSignInAdaptiveMfaTriggered webhook event is emitted when adaptive MFA forces MFA during sign-in.

Optional MFA onboarding

A new MFA onboarding page is added for users who are not required to set up MFA.

• After credential verification, users can be explicitly asked whether they want to enable optional MFA for better account security.
• This is especially useful when passkey sign-in is enabled, since passkeys can be used for both sign-in and MFA verification, and some users may not want to enable them as an MFA factor at the same time.

User session management

This release adds user session management across APIs and Console.

Account APIs:

• GET /my-account/sessions
• DELETE /my-account/sessions/:sessionId

Management APIs:

• GET /users/:userId/sessions
• GET /users/:userId/sessions/:sessionId
• DELETE /users/:userId/sessions/:sessionId

Session revocation details:

• revokeGrantsTarget=all revokes grants for all apps.
• revokeGrantsTarget=firstParty revokes only first-party app grants.
• When grants are revoked, previously issued opaque access tokens and refresh tokens for those grants are invalidated.

Permission and scope updates:

• A new account center permission setting session is added with off, readOnly, and edit.
• A new user scope urn:logto:scope:sessions is introduced to gate session-related account API access.

Session context:

• User IP, user agent, and GEO location can now be recorded in interaction submission data and returned in session.lastSubmission.

Console support:

• A new Active sessions section is added on the user details page.
• Users can navigate to a dedicated session details page.
• Sessions can be revoked from the session details page.
• Revoking a session removes the sign-in session and revokes associated first-party app grants, forcing reauthentication for future requests.

User application grant management

This release introduces application grant management endpoints for both account and management APIs.

Account API:

• GET /my-account/grants to list active application grants for the current user.
• DELETE /my-account/grants/:grantId to revoke a specific grant for the current user.

Management API:

• GET /users/:userId/grants to list active application grants for a given user.
• DELETE /users/:userId/grants/:grantId to revoke a specific grant for a given user.

Grant listing supports an optional appType query parameter:

• appType=firstParty
• appType=thirdParty
• Omit appType to return all active grants

Authorized third-party apps in Console

Console now includes an Authorized third-party apps section on the user details page.

• It lists active third-party application authorizations for a user.
• It shows app name, app ID, and access creation time.
• It includes a revoke action with a confirmation modal.
• Revoking an app removes all active third-party grants associated with that app for the user.

App-level concurrent grant limits

This release adds app-level concurrent grant limits.

Core and schemas:

• Application customClientMetadata now supports an optional maxAllowedGrants field.
• A new OIDC authorization.success event listener validates concurrent grants for the current authorization client and user.
• When the active grant count exceeds the configured limit, the oldest grants are revoked automatically.

Console:

• A new Concurrent device limit section is added to the Application details page.
• Developers can configure the maximum number of concurrent active grants per user for the current app.

Configurable OIDC session TTL

This release adds configurable OIDC session TTL support.

Core:

• OIDC provider initialization now respects oidc.session.ttl from logto-config.
• When oidc.session.ttl is provided, it overrides the default session TTL.
• New management APIs are added:
  • GET /api/configs/oidc/session
  • PATCH /api/configs/oidc/session

Schemas:

• A new optional oidc.session.ttl field is added to logto-config.
• The value is configured in seconds.
• If not provided, the default remains 14 days.

For OSS deployments:

• Restart the service instance after config changes so the server can pick up updated OIDC config.
• To apply OIDC config updates automatically without restart, enable central Redis cache.

Tenant settings page and OIDC settings in Console

Console now exposes tenant-level OIDC settings in OSS.

• A new Tenant -> Settings page is added.
• The original Signing keys page is deprecated and removed.
• A new OIDC settings tab is added under Tenant -> Settings.
• Signing key configuration is migrated to Settings -> OIDC settings.
• A new Session maximum time to live field is added to configure tenant-level session TTL in days.
• The Console field uses days for input and display, while the underlying OIDC session TTL config and API use seconds.

Account Center improvements

This release includes several improvements to the out-of-the-box Account Center.

• Added support for replacing the authenticator app through a dedicated /authenticator-app/replace route.
• Added a new PUT endpoint in Account API for idempotent TOTP replacement.
• Added support for the identifier URL parameter to pre-fill identifier input fields.
• Added support for overriding the out-of-the-box Account Center language with the ui_locales URL parameter.

Access token exchange for service-to-service delegation

Logto now supports access token exchange for service-to-service delegation.

• The standard subject_token_type value urn:ietf:params:oauth:token-type:access_token now supports access token exchange.
• Both opaque and JWT access tokens issued by Logto can be exchanged for new access tokens with different audiences.
• This enables service-to-service delegation scenarios.

Token validation order:

1. If the token starts with sub_, treat it as a legacy impersonation token.
2. Try to find it as an opaque access token via oidc-provider.
3. Fall back to JWT verification using the issuer's JWK set.

Additional detail:

• Access tokens are not consumption-tracked, so the same token can be exchanged multiple times.
• A new urn:logto:token-type:impersonation_token type is added for explicit impersonation token handling.

Password-hash export for migrations

The following endpoints now support an includePasswordHash query parameter:

• `GET /user...

v1.37.1

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/core-kit@2.7.1

• Add extended id token claims exports

v1.37.0

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

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

v1.35.0

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.

v1.34.0

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.

v1.33.0

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.

v1.32.0

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

v1.31.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": "john.doe@example.com",
  "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

v1.30.1

Note

The v1.30.0 release contained an CLI issue affecting DB upgrade, and have been resolved this in the v1.30.1 patch release. We strongly recommend upgrading to v1.30.1.

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.

Note

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.

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.