v1.24.1

New connectors:

• X (Twitter) social connector
• Slack social connector
• LinkedIn social connector
• Line social connector
• Amazon social connector

Bug fixes

• cb26102: fix cli add offical connectors command missing connectors bug
  Fix the bug when running the cli commend logto connectors add --official, only 8 connectors are fetched from npm registry.
  This fix update logic to query additional pages of results when fetching connectors from the npm registry.

• 0b785ee: display JWKS URI on application details page

• e7accfd: prevent i18n context contamination by using request-scoped instances
  This bug fix resolves a concurrency issue in i18n handling by moving from a global i18next instance to request-scoped instances.

  Problem

  When handling concurrent requests:

  • The shared global i18next instance's language was being modified via changeLanguage() calls.
  • This could lead to race conditions where requests might receive translations in unexpected languages.
  • Particularly problematic in multi-tenant environments with different language requirements.

  Solution

  • Updated koaI18next middleware to create a cloned i18next instance for each request.
  • Attach the request-scoped instance to Koa context (ctx.i18n) All subsequent middleware and handlers should now use ctx.i18n instead of the global i18next instance.
  • Maintains the global instance for initialization while preventing cross-request contamination

• a5990ec: fixes an incorrect condition check in the verification code flow where isNewIdentifier was using inverted logic for email and phone comparisons.

  Changes

  • Corrected isNewIdentifier boolean logic to use identifier.value !== user.primaryEmail for email checks
  • Fixed phone number comparison to properly use identifier.value !== user.primaryPhone

  Impact

  This fixes a regression where:

  • Verification codes for existing emails/phones were incorrectly using theBindNewIdentifier template
  • New identifiers were mistakenly getting the UserPermissionValidation template
  • Affected both email and phone verification flows

• 28643c1: fix the email/phone identifier conflict handling logic during user registration.

  When a user attempts to register with an email/phone that already exists:

  Previous Behavior

  "Sign in instead" modal will be shown when:

  • The email/phone identifier has been verified through a verification code validation
  • Identifier type (email/phone) was enabled in sign-in methods

  This caused an issue when:

  • Only password authentication method was enabled in the sign-in method settings.
  • When users clicked "Sign in instead" action button, the API call will throw an sign-in method not enabled error. Which is confusing for the user.

  Expected behavior: Show the "Email/phone already exists" error modal directly. If only password authentication is enabled. User should not be able to sign in with email/phone directly.

  Fixed Behavior

  Shows the "Sign in instead" modal if:

  • The email/phone identifier type is enabled in the sign-in method settings and the verification code is enabled for the identifier.

  Otherwise, shows the "Email/phone already exists" error modal directly.

• bd18da4: properly filter WeChat connectors by platform (Web | Native) in SSR sign-in experience settings

  Previously, platform-based social connector filtering was applied during the sign-in experience settings fetch process but not in the SSR sign-in experience data. As a result, platform-specific connectors were not correctly filtered when rendering the page using SSR data.

  This update ensures that the same filtering logic is applied to SSR sign-in experience data, resolving the issue.

  Affected connectors: WeChat Web and WeChat Native.

v1.24.0

Support SAML applications

Logto now supports acting as a SAML identity provider (IdP), enabling enterprise users to achieve secure Single Sign-On (SSO) through the standardized SAML protocol. Key features include:

• Full support for SAML 2.0 protocol
• Flexible attribute mapping configuration
• Metadata auto-configuration support
• Enterprise-grade encryption and signing

View full documentation for more details.

Add HTTP email connector

Users can now use HTTP email connector for sending emails.
The HTTP email connector allows you to send emails via HTTP call. To use the HTTP email connector, you'll need to have your own email service that expose an HTTP API for sending emails. Logto will call this API when it needs to send an email. For example, when a user registers, Logto will call the HTTP API to send a verification email.

Bug fixes

• 62eb8ed Fixed the issue where the CLI could not correctly initialize the Logto instance or deploy database alterations.
• bf2d300 Fixed the bug that a user accepts an invitation and join an organization does not trigger the Organization.Membership.Updated webhook.

v1.23.1

Support custom endpoint and addressing style for S3

Add support for configurable S3 endpoint and addressing style (path-style/virtual-hosted)
to improve compatibility with S3-compatible storage services.

• Add forcePathStyle option to control URL addressing style
• Fix custom endpoint support implementation
• Improve URL generation logic for different configurations

Bug fixes

Fix the broken image on Logto console sign-in page

Remove the image element's cross-origin="anonymous" attribute.

Some public image resources may not have the proper cross-origin headers configured, those images may fail to load when the cross-origin="anonymous" attribute is present.
Since sign-in page image elements are only used for display purposes, Logto does not need to access the image data, so the cross-origin="anonymous" attribute is not necessary.To make the image elements more compatible with public image resources, remove the attribute from the image elements.

v1.23.0

Customizable MFA prompt policy

You can now customize the MFA prompt policy in the Console.

First, choose if you want to enable Require MFA:

• Enable: Users will be prompted to set up MFA during the sign-in process, which cannot be skipped. If the user fails to set up MFA or deletes their MFA settings, they will be locked out of their account until they set up MFA again.
• Disable: Users can skip the MFA setup process during the sign-up or sign-in flow.

If you choose to Disable, you can continue to choose the MFA setup prompt:

• Do not ask users to set up MFA.
• Ask users to set up MFA during registration (skippable, one-time prompt). The same prompt as the previous policy (UserControlled)
• Ask users to set up MFA on their next sign-in attempt after registration (skippable, one-time prompt).

Relaxed redirect URI restrictions

We have been following the industry best practices for OAuth2.0 and OIDC from the start. However, in the real world, there are things we cannot control, like third-party services or operation systems like Windows.

This update relaxes restrictions on redirect URIs to allow the following:

• A mix of native and HTTP(S) redirect URIs. For example, a native app can now use a redirect URI like https://example.com/.
• Native schemes without a period (.). For example, myapp://callback is now allowed.

When such URIs are configured, Logto Console will display a prominent warning. This change is backward-compatible and will not affect existing applications.

We hope this change will make it easier for you to integrate Logto with your applications.

New connectors

• 3fa2b79 Added Xiaomi social connector (credit @u0x01 ).
• 3004ae9 Added YunPian SMS connector (credit @u0x01 ).

Bug fixes

• 2178589 Fixed the CLI command for fetching official connectors by updating the npm registry API integration.

v1.22.0

Account API

The new Account API is now available, giving end users direct API access without needing to go through the Management API. With this new API:

• Users can directly manage their profiles, including basic information, password, email, and phone
• Admins have full control over access settings for each field
• Integration is simple with client.getAccessToken() for authorization
• Social identities management is supported out of the box

Check out the Interact with Account API for more details.

Microsoft EntraID SSO connector enhancement

Added trustUnverifiedEmail setting for Microsoft EntraID OIDC SSO connector.

This addresses a common issue where email addresses from EntraID weren't being synced to Logto because they lacked explicit verification.

Organizations can now choose to trust these email addresses, enabling smoother user onboarding through EntraID SSO.

You can configure this setting in the EntraID OIDC SSO connector settings page in the Logto console or through the management API.

Sign-in experience improvements

Support contact information

Added support email and website information display on error pages.

When users encounter issues (like 404 errors or social callback failures), they can now easily find ways to contact support for assistance.

You may configure the support email and website info in the Sign-in experience > Content > Support settings in the Logto Console or through the management API.

Unknown session handling

Introduced unknown session redirect URL configuration.
This helps users who land on sign-in pages with expired sessions or through bookmarked URLs - instead of seeing a 404 error, they can be automatically redirected to a specified URL to restart their authentication process.

You may configure the unknown session redirect URL in the Sign-in experience > Sign-up and sign-in > Advanced options settings in the Logto Console or through the management API.

v1.21.0

GatewayAPI SMS connector

You can now send SMS messages via GatewayAPI.

Australia region

The Australia region is now available in Logto Cloud.

Improvements and fixes

• #6734 update Google Connector default prompts to be select_account
• #6630 fix an issue that prevent mp4 video from playing in custom sign-in pages on Safari browser
• #6674 add environment variable to override default database connection timeout

New Contributors

• @michaelgiraldo made their first contribution in #6615
• @bpow made their first contribution in #6328
• @GeisonPiegas made their first contribution in #6642
• @buchen made their first contribution in #6655
• @luis815 made their first contribution in #6674

Coming Soon: Account API

The new Account API is on its way, designed to give end users direct API access without needing to go through the Management API. Here’s a sneak peek of what you can expect:

1. Direct access: The Account API empowers end users to directly access and manage their own account profile without requiring the relay of Management API.
2. User profile and identities management: Users can fully manage their profiles and security settings, including the ability to update identity information like email, phone, and password, as well as manage social link connections. May also support MFA and SSO in the future.
3. Global access control: Admin will have full, global control over access settings, can customize each fields.
4. Seamless authorization: Authorizing is easier than ever! Simply use client.getAccessToken() to obtain an access token and attach it to the Authorization header.

v1.20.0

Arabic translation and RTL support

• #6422 Added new Arabic language translation to both Console and Experience UI (credit @zaaakher).
• Improved UI layout and details to better support RTL languages.

Personal access token (PAT)

Personal access tokens (PATs) provide a secure way for users to grant access tokens without using their credentials and interactive sign-in.

You can create a PAT by going to the user's detail page in Console or using the Management API POST /users/:userId/personal-access-tokens.

Refer to documentation for more details.

Support additional first-screen options

In addition to sign-in and register, we now enabled more options that allowing developers to customize the initial screen presented to users. These new first-screen options are:

• identifier:sign_in: Only display specific identifier-based sign-in methods to users.
• identifier:register: Only display specific identifier-based registration methods to users.
• reset_password: Allow users to directly access the password reset page.
• single_sign_on: Allow users to directly access the single sign-on (SSO) page.

Refer to documentation for more details.

New connectors

• #6227 Added Kook connector (credit @Misaka-L).
• #6514 Added Patreon connector (credit @devtekve).
• #6529 Added GitLab connector (credit @devtekve).

Improvements

• #6400 Supported login_hint as additional sign-in parameter.
• #6445 Implemented well-known swagger endpoints.
• #6451 Split translate command from @logto/cli to make the CLI small and simple.
• #6451 Added a dedicated @logto/translate package to translate i18n phrases in Console and Experience.
• #6523 Supported entering name while creating a user in Console.
• #6525 Added new query parameter parse_error and explicitly set it to false to return raw OIDC error message only.
• #6532 Added denyAccess() api to custom JWT context in order to conditionally block user token request.
• #6534 Supported nested attribute profile mapping in OAuth connector (credit @devtekve).
• #6543 Added hasPassword property to /users Management API response.
• #6544 Added user password information in user details. Admin can easily check if a user has set password or not, and can then perform set/reset action accordingly.
• #6567 Added new management API to check password against current password policy settings.

Fixes

• #6425 Prevented potential error caused by cached identifiers across Experience pages.
• #6441 Fixed the issue that blocked users from creating Custom JWT.
• #6481 Fixed wecom connector platform. Use Universal instead of null.
• #6536 Set lang attribute correctly to <html> in Console, preventing unexpected browser translator prompt.
• #6560 Allowed linking new social identity to an existing user account when registration is disabled.
• #6576 Prevented user registration and profile fulfillment with SSO-only email domains.

v1.19.0

User impersonation (RFC 8693: OAuth 2.0 Token Exchange)

Added support for user impersonation via Token Exchange:

• New Management API endpoint POST /subject-tokens to request a subject_token for token exchange use.
• Updated the OIDC POST /oidc/token endpoint with a new grant type urn:ietf:params:oauth:grant-type:token-exchange to exchange a subject_token for a user-impersonated access_token.

See User impersonation for more details.

Application level custom_data

Added a new arbitrary object field custom_data to applications. This field can store any additional information not defined in the standard Application schema.

Click to expand Management API updates

• New PATCH /api/applications/{applicationId}/custom-data endpoint to patch update the custom_data field of an application.
• Update PATCH /api/applications/{applicationId} endpoint to allow overwriting the custom_data field.

Click to expand Console updates

Added a new custom data JSON editor to the application details page (except for Protected Apps).

Multiple app secrets management

Secure apps (machine-to-machine, traditional web, Protected) can now have multiple app secrets with expiration. This allows for secret rotation and provides an even safer experience.

Note

The legacy secret created before this feature can still be used for client authentication. However, it is recommended to delete the old ones and create new secrets with expiration for enhanced security.

Click to expand management API updates

• GET /api/applications/{applicationId}/secrets: List all the secrets of an application.
• POST /api/applications/{applicationId}/secrets: Create a new secret for an application.
• DELETE /api/applications/{applicationId}/secrets/{name}: Delete a secret of an application by name.
• PATCH /api/applications/{applicationId}/secrets/{name}: Update a secret of an application by name.
• DELETE /api/applications/{applicationId}/legacy-secret: Delete the legacy secret of an application and replace it with a new one.

Click to expand Console updates

To manage your application secrets, go to Logto Console -> Applications -> Application Details -> Endpoints & Credentials.

The original app secret read-only input field is now replaced with a new secrets management table. You can create, update, and delete secrets in this table.

Organization and application level branding

Organization logo

Now it's able to set light and dark logos for organizations. You can upload the logos in the organization settings page.

Also, it's possible to override the sign-in experience logo from an organization. Simply add the organization_id parameter to the authentication request. In most Logto SDKs, it can be done by using the extraParams field in the signIn method.

For example, in the JavaScript SDK:

import LogtoClient from '@logto/client';

const logtoClient = new LogtoClient(/* your configuration */);

logtoClient.signIn({
  redirectUri: 'https://your-app.com/callback',
  extraParams: {
    organization_id: '<organization-id>',
  },
});

The value <organization-id> can be found in the organization settings page.

If you could not find the extraParams field in the SDK you are using, please let us know.

Application level branding

You can now set logos, favicons, and colors for your app. These settings will be used in the sign-in experience when the app initiates the authentication flow. For apps that have no branding settings, the omni sign-in experience branding will be used.

If organization_id is provided in the authentication request, the app-level branding settings will be overridden by the organization's branding settings, if available.

Performance improvements

Support experience app server-side rendering

Logto now injects the sign-in experience settings and phrases into the index.html file for better first-screen performance. The experience app will still fetch the settings and phrases from the server if:

• The server didn't inject the settings and phrases.
• The parameters in the URL are different from server-rendered data.

Package build improvements

• Use tsup to build the connector packages. This will make the build process faster, and should not affect the functionality of the packages.
• User Vite for transpilation and bundling of the @logto/console, @logto/demo-app, and @logto/experience packages. Removed ParcelJS and replaced with Vite. No breaking changes should be expected.

Bug fixes

Fix the jsonb update behavior of the PATCH /api/applications/{applicationId} endpoint

All the jsonb fields of the Application object should be updated in the replace mode instead of the merge mode. This change will make the PATCH method more predictable and consistent with the Restful API design.

• Update the jsonb field update mode from merge to replace in the PATCH /api/applications/{applicationId} endpoint.
• Update the API jsonb field input parameters validation from partial to full in the PATCH /api/applications/{applicationId} endpoint.
• Affected fields: oidc_client_metadata, custom_client_metadata, protected_app_metadata and custom_data.

Note

If you are using Logto console to update the Application settings, you should not be affected by this change. API users who are using the PATCH method to update the Application jsonb field settings should be aware of this change. The PATCH method will now replace the whole jsonb field with the new input data. Any partial input data of the affected fields will be rejected.

Fix some of the webhooks event payload always return API response status 404 bug

Affected webhook events: Role.Scopes.Updated, Organizations.Membership.Updates.

The API response status code returned from the webhook event payload was always 404. That was caused by inserting the webhook event payload before the API response context was set.

Since we only trigger the webhook when the event is successfully processed, the status code should always be 2xx.

This issue have been fixed by moving the webhook event payload insertion after the API response context is set.

Other improvements

• The favicon for the dark theme now can be set in the sign-in experience branding settings.
• Add new password digest algorithms: Argon2d and Argon2id. Users with those algorithms will be migrated to Argon2i upon successful sign-in.
• The browser list configuration for @logto/experience has been synced with what is stated in README.md.
• Improve swagger auth description. Use the native OpenAPI OAuth2 security scheme instead of the custom HTTP header-based security schema.

v1.18.0

Note

Our public roadmap has come back. Upvote the features you need and feel free to leave comments!

Compliance

We are SOC 2 Type I compliant, officially! 🎉 A Type II audit is on the horizon.

Just-in-Time provisioning for organizations

This feature allows users to automatically join the organization and be assigned roles upon their first sign-in through some authentication methods. You can set requirements to meet for Just-in-Time provisioning.

To use this feature, head to the organization settings and find the "Just-in-Time provisioning" section. Management APIs are also available to configure this feature via routes under /api/organizations/{id}/jit. To learn more, see Just-in-Time provisioning.

Email domains

New users will automatically join organizations with Just-in-Time provisioning if they:

• Sign up with verified email addresses, or;
• Use social sign-in with verified email addresses.

This applies to organizations that have the same email domain configured.

Click to expand

To enable this feature, you can add email domain via the Management API or the Logto Console:

• We added the following new endpoints to the Management API:
  • GET /organizations/{organizationId}/jit/email-domains
  • POST /organizations/{organizationId}/jit/email-domains
  • PUT /organizations/{organizationId}/jit/email-domains
  • DELETE /organizations/{organizationId}/jit/email-domains/{emailDomain}
• In the Logto Console, you can manage email domains in the organization details page -> "Just-in-Time provisioning" section.

SSO connectors

New or existing users signing in through enterprise SSO for the first time will automatically join organizations that have Just-in-Time provisioning configured for the SSO connector.

Click to expand

To enable this feature, you can add SSO connectors via the Management API or the Logto Console:

• We added the following new endpoints to the Management API:
  • GET /organizations/{organizationId}/jit/sso-connectors
  • POST /organizations/{organizationId}/jit/sso-connectors
  • PUT /organizations/{organizationId}/jit/sso-connectors
  • DELETE /organizations/{organizationId}/jit/sso-connectors/{ssoConnectorId}
• In the Logto Console, you can manage SSO connectors in the organization details page -> "Just-in-Time provisioning" section.

Default organization roles

You can also configure the default roles for users provisioned via this feature. The default roles will be assigned to the user when they are provisioned.

Click to expand

To enable this feature, you can set the default roles via the Management API or the Logto Console:

• We added the following new endpoints to the Management API:
  • GET /organizations/{organizationId}/jit/roles
  • POST /organizations/{organizationId}/jit/roles
  • PUT /organizations/{organizationId}/jit/roles
  • DELETE /organizations/{organizationId}/jit/roles/{organizationRoleId}
• In the Logto Console, you can manage default roles in the organization details page -> "Just-in-Time provisioning" section.

Machine-to-machine apps for organizations

This feature allows machine-to-machine apps to be associated with organizations, and be assigned with organization roles.

OpenID Connect grant

The client_credentials grant type is now supported for organizations. You can use this grant type to obtain an access token for an organization.

Click to expand Console updates

• Add a new "machine-to-machine" type to organization roles. All existing roles are now "user" type.
• You can manage machine-to-machine apps in the organization details page -> Machine-to-machine apps section.
• You can view the associated organizations in the machine-to-machine app details page.

Click to expand Management API updates

A set of new endpoints are added to the Management API:

• /api/organizations/{id}/applications to manage machine-to-machine apps.
• /api/organizations/{id}/applications/{applicationId} to manage a specific machine-to-machine app in an organization.
• /api/applications/{id}/organizations to view the associated organizations of a machine-to-machine app.

Swagger (OpenAPI) improvements

Note

Shout out to @mostafa for bringing these amazing improvements to Logto!

Build operationId for Management API in OpenAPI response

As per the specification:

operationId is an optional unique string used to identify an operation. If provided, these IDs must be unique among all operations described in your API.

This greatly simplifies the creation of client SDKs in different languages, because it generates more meaningful function names instead of auto-generated ones, like the following examples:

- org, _, err := s.Client.OrganizationsAPI.ApiOrganizationsIdGet(ctx, req.GetId()).Execute()
+ org, _, err := s.Client.OrganizationsAPI.GetOrganization(ctx, req.GetId()).Execute()

- users, _, err := s.Client.OrganizationsAPI.ApiOrganizationsIdUsersGet(ctx, req.GetId()).Execute()
+ users, _, err := s.Client.OrganizationsAPI.ListOrganizationUsers(ctx, req.GetId()).Execute()

Fixed OpenAPI schema returned by the GET /api/swagger.json endpoint

• The : character is invalid in parameter names, such as organizationId:root. These characters have been replaced with -.
• The tenantId parameter of the /api/.well-known/endpoints/{tenantId} route was missing from the generated OpenAPI spec document, resulting in validation errors. This has been fixed.

Backchannel logout support

We've enabled the support of OpenID Connect Back-Channel Logout 1.0.

To register for backchannel logout, navigate to the application details page in the Logto Console and locate the "Backchannel logout" section. Enter the backchannel logout URL of your RP and click "Save".

You can also enable session requirements for backchannel logout. When enabled, Logto will include the sid claim in the logout token.

For programmatic registration, you can set the backchannelLogoutUri and backchannelLogoutSessionRequired properties in the application oidcClientMetadata object.

Sign-in experience

Support Google One Tap

When you added Google as a social connector, you can now enable Google One Tap to provide a smoother sign-in experience for your users with Google accounts.

Head to the Google connector settings in the Logto Console and switch on the "Google One Tap" option.

To learn more about Google One Tap, see Enable Google One Tap.

Allow skipping manual account linking during sign-in

You can find this configuration in Console -> Sign-in experience -> Sign-up and sign-in -> Social sign-in -> Automatic account linking.

When switched on, if a user signs in with a social identity that is new to the system, and there is exactly one existing account with the same identifier (e.g., email), Logto will automatically link the account with the social identity instead of prompting the user for account linking.

Agree to terms polices for sign-in experience

We've added a new configuration to allow you to set the terms of service agreement policy for sign-in experience:

• Automatic: Users automatically agree to terms by continuing to use the service.
• ManualRegistrationOnly: Users must agree to terms by checking a box during registration, and don't need to agree when signing in.
• Manual: Users must agree to terms by checking a box during registration or signing in.

Console improvements

• Added Ruby and Chrome extension guide.
• Display OIDC issuer endpoint in the application details form.
• Application guides have been reorganized to provide a better developer experience.
• Now you can view and update user's profile property in the user settings page.
• Improved machine-to-machine application integration user experience.
• Fixed a regression bug that error toasts pop up in audit log when logs are associated with deleted applications.

Other improvements

• Added hasPassword to custom JWT user context.
• Connector: Google and Azure AD connectors now support custom prompt.
• Support per-organization multi-factor authentication requirement:
  • An organization can now require its member to have multi-factor authentication (MFA) configured. If an organization has this requirement and a member does not have MFA configured, the member will not be able to fetch the organization access token.
• A dev panel is available after you sign in to the live preview.
• Pagination is now optional for GET /api/organizations/{id}/users/{userId}/roles. If you don't provide page and limit query parameters, the API will return all roles.
• Added user detail data payload to the User.Deleted webhook event.

v1.17.0

Note

The US region is now available in Logto Cloud.

New webhook events

We are introducing a series of new webhook events triggered by data updates, mostly through the Management API, which are useful for various automation scenarios. These include user events, role events, organization events, etc. For the full list of events, please see Webhook events.

To improve clarity, the Console now displays the raw event key instead of the translated text for webhooks. For example, "Create new account" is now displayed as "PostRegister".

User default roles

You can now set default roles for users by visiting the role details page, clicking on the "General" tab, and then enabling the "Default role" switch. Once activated, all new users will automatically be assigned all the default roles upon account creation.

This enables you to configure Logto apps with resources and scopes associated with a default role, ensuring new users receive the necessary scopes right after registration.

Note

All existing users will not be affected.

Improvements

• #5915 Added DingTalk web connector (credit @anyidea).
• #5908 A pre-configured role with Management API access will be created when seeding the database.
• #5955 Added sso_identities ID token claim to the userinfo endpoint response. It is an array of objects that stores the current user's SSO identities.
  • To request this claim, you can use the identities scope which is shared with social identities.
• #5950 In OSS, show the current version number in the top right corner.
• Improved error handling and deleted item display on Console.
• Show global loading state on page redirects to prevent user interactions.
• Updated documentation reference links.

Fixes

• #5925 GitHub connector: Fix a potential blocking error in when GET /users/emails responds 403
• #5912 Fixed Microsoft EntraID OIDC SSO connector invalid authorization code response issue