Logto product updates

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

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.