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.

v1.29.0

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:

Property	Description	Type
interactionEvent	The interaction event of the current user interaction	SignIn or Register
userId	The user id of the current user interaction	string
verificationRecords	A list of verification records submitted by the user to identify and verify their identity during interactions.	VerificationRecord[]

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.

v1.28.0

Email blocklist policy

We've introduced a comprehensive email blocklist policy system with a dedicated settings page in the Logto console's Security section. This new feature provides granular control over which email addresses can be used for sign-up and account linking.

With this new policy, you can:

• Customize email restrictions through a flexible blocklist system
• Prevent sign-ups or account linking with specific email addresses or domains
• Control email subaddressing (e.g., 'user+tag@example.com')

Phone number validation and normalization

We've improved phone number handling to ensure consistent format validation and storage:

• Added proper handling for phone numbers with leading zeros in national format
  • Normalizes numbers like +61 (0)2 1234 5678 to +61 2 1234 5678
  • Users can sign in with either format (with or without leading zero)
  • Existing accounts can still use their original phone number format
• Implemented stricter phone number format validation in database
• Fixed phone number format inconsistencies (GitHub issue #7371, thanks for @mrfrase3)

QQ social connector

We've expanded our social sign-in options by introducing a new QQ social connector specifically designed for web applications, enabling seamless QQ account integration for your users. (Contributed by @yenharvey in #7380)

OIDC connector

We've updated our OIDC connector configuration to make the userinfo_endpoint field optional. The system now intelligently handles user data extraction based on available endpoints, providing a more flexible authentication solution while maintaining OIDC specification compliance.

This update enables:

• Seamless integration with Azure AD B2C SSO applications
• Automatic fallback to id_token claims when userinfo_endpoint is unavailable
• Full compatibility with standard OIDC providers
• Removal of integration barriers for non-standard OIDC implementations

Improvements

• Enhanced translation key synchronization to handle empty files during sync process, eliminating manual intervention needs
• Upgraded to gpt-4.1 as the default translation model for better cost-efficiency
• Improved CAPTCHA configuration visibility in console with persistent toggle display
• Updated CAPTCHA settings navigation to /security/captcha

Bug fixes

• Added missing CAPTCHA box to identifier sign in form

Full Changelog: v1.27.0...v1.28

v1.27.0

Security center in Logto Console

We have introduced a new"Security" page in the Logto console, which includes the following features:

• Password policy: This feature has been migrated from the "Sign-in Experience" page to the new "Security" page.
• CAPTCHA: Enable CAPTCHA for sign-up, sign-in, and password recovery to mitigate automated threats.
• Identifier lockout: Temporarily lock an identifier after multiple failed authentication attempts (e.g., consecutive incorrect passwords or verification codes) to prevent brute force access.

Refer to documentation for more details.

Captcha bot protection

As mentioned in the above "Security" update, you can now enable CAPTCHA bot protection for your sign-in experience with providers such as Google reCAPTCHA enterprise and Cloudflare Turnstile.

To enable CAPTCHA bot protection, you need to:

1. Go to Console > Security > CAPTCHA > Bot protection.
2. Select the CAPTCHA provider you want to use.
3. Configure the CAPTCHA provider by following our step-by-step guide.
4. Save the settings.
5. Enable CAPTCHA in the Security page.

Then take a preview of your sign-in experience to see the CAPTCHA in action.

Refer to documentation for more details.

Identifier lockout (sentinel)

The identifier lockout has always been there protecting your Logto instance. However, previously it is hard-coded and not configurable. Now you can fully customize and override the default rules in the Security center.

This update includes the follow 3 parts:

1. Maximum failed attempts:

• This limits the number of consecutive failed authentication attempts per identifier within an hour. If the limit is exceeded, the identifier will be temporarily locked out.
• Default value: 100

2. Lockout duration (minutes):

• This specifies the period during which all authentication attempts for the given identifier are blocked after exceeding the maximum failed attempts.
• Default value: 60 minutes

3. Manual unblock:

A new API endpoint has been introduced to manually unblock a specified list of identifiers. This feature is useful for administrators to unlock users who have been temporarily locked out due to exceeding the maximum failed attempts.

Endpoint: POST /api/sentinel-activities/delete

This endpoint allows for the bulk deletion of all sentinel activities within an hour in the database based on the provided identifiers, effectively unblocking them.

Refer to documentation for details.

Magic link (one-time token) support

You can now use the "one-time token" to compose magic links, and send them to the end user's email.

With a magic link, one can register a new account or sign in directly to the application, without the need to enter a password, or input verification codes.

You can also use magic link to invite users to your organizations.

Example API request to create a one-time token

POST /api/one-time-tokens

Request payload:

{
  "email": "user@example.com",
  // Optional. Defaults to 600 (10 mins).
  "expiresIn": 3600,
  // Optional. User will be provisioned to the specified organizations upon successful verification.
  "context": {
    "jitOrganizationIds": ["your-org-id"],
  },
}

Compose your magic link

After you get the one-time token, you can compose a magic link and send it to the end user's email address. The magic link should at least contain the token and the user email as parameters, and should navigate to a landing page in your own application. E.g. https://yourapp.com/landing-page.

Here's a simple example of what the magic link may look like:

https://yourapp.com/landing-page?token=YHwbXSXxQfL02IoxFqr1hGvkB13uTqcd&email=user@example.com

Refer to documentation for more details.

Bump node to v22

We've updated Node.js to v22 for better performance and security.

Improvements

• f419382: respond 404 for non-existing paths in /assets
• 7dbceda: move password encyption to separate worker thread
• cfedfb3: clean up legacy Experience package
• 752d406: support string-typed boolean claims in OIDC connector
• 59c3984: add Ukrainian translation to Experience (credit @HighError)
• ba76210: convert Windows absolute paths to file URLs for dynamic imports (credit @jtmaveryk)

Security updates and vulnerability fixes

New Contributors

• @HighError made their first contribution in #7205
• @jtmaveryk made their first contribution in #7126

Full Changelog: v1.26.0...v1.27

v1.26.0

Support multiple sign-up identifiers

Logto now supports configuring multiple required identifiers for user registration. This enhancement extends the previous single-identifier limitation, enabling a more comprehensive sign-up process.

Sign-in experience schema

Introduces a new optional field, secondaryIdentifiers, to the sign-in experience sign-up settings. This enhancement allows developers to specify multiple required user identifiers during the user sign-up process. Available options include email, phone, username and emailOrPhone.

The difference between signUp.identifiers and new signUp.secondaryIdentifiers:

Primary identifiers (signUp.identifiers):

• Maintains backward compatibility with existing sign-in experience settings
• Represents the initial registration form
• Uses OR logic: Only one type of identifier will be collected
• Special case: [email, phone] allows either email OR phone registration, treated as a single requirement.

Secondary identifiers (signUp.secondaryIdentifiers):

• Optional
• New field introduced for multi-identifier support
• Collects additional required identifiers after primary registration
• Uses AND logic: all configured identifiers are mandatory
• Supports emailOrPhone type: requires either email OR phone, treated as a single requirement

Examples:

Example 1: Username with Required Email and Phone

Primary: username
Secondary: 'emailandphone`

{
  "identifiers": ["username"],
  "secondaryIdentifiers": [
    {
      "type": "email",
      "verify": true
    },
    {
      "type": "phone",
      "verify": true
    }
  ],
  "verify": true,
  "password": true
}

Example 2: Username with Either Email or Phone

Primary: username
Secondary: emailOrPhone

{
  "identifiers": ["username"],
  "secondaryIdentifiers": [
    {
      "type": "emailOrPhone",
      "verify": true
    }
  ],
  "verify": true,
  "password": true
}

Example 3: Email/Phone with Required Username

Primary: email OR phone
Secondary: username

{
  "identifiers": ["email", "phone"],
  "secondaryIdentifiers": [
    {
      "type": "username",
      "verify": true
    }
  ],
  "verify": true,
  "password": false
}

Console updates

Enhanced Sign-up Configuration UI:

• Introduced a multi-selector interface replacing the previous single-identifier selector
• Added drag-and-drop functionality for prioritizing identifiers
• The first identifier in the list serves as the primary identifier (signUp.identifiers)
• Subsequent identifiers are stored as secondary identifiers (signUp.secondaryIdentifiers)

Enhanced sign-in experience configuration

We've relaxed several configuration constraints to give you more flexibility in customizing your authentication flows.

1. The password requirement is now optional when using username as a sign-up identifier. Please note, when configuring username as the sole sign-up identifier with password disabled, users will be unable to authenticate after registration. Ensure at least one of the following:

   • Enable password requirement at sign-up
   • Configure additional sign-up identifiers

2. Removed the constraint requiring sign-up identifiers to be enabled as sign-in methods. We have fully decoupled the sign-up identifier settings from the sign-in methods. Developers can now require as many user identifiers as needed during the sign-up process without impacting the sign-in process.

3. Removed the requirement for password verification across all sign-in methods when password is enabled for sign-up.

Experience package migration

In this release, we have transitioned the user sign-in experience from the legacy @logto/experience-legacy package to the latest @logto/experience package. This change fully adopts our new Experience API, enhancing the underlying architecture while maintaining the same user experience.

• The sign-in experience front-end now uses the @logto/experience package by default.
• Fully adopts our new Experience API for improved performance and maintainability
• Maintains complete feature parity with no visible changes to end-users
• Legacy Interaction API and @logto/experience-legacy will be deprecated in future releases.

CLI updates

@logto/translate

• Improve the OpenAI prompt to better support i18n plural form suffixes

• make method isLanguageTag case-insensitive

  Language tag case inconsistency was causing translation mismatches across packages:

  • @logto/phrases and @logto/phrases-experience: using lowercase tags (e.g., pt-br, zh-cn)
  • @logto/language-kit: using mixed-case tags (e.g., pt-BR, zh-CN)

  Updated isLanguageTag function in language kit to be case-insensitive, ensuring:

  • Consistent language tag matching regardless of case
  • Proper detection of all language tags by translate CLI tool
  • Fixed missing translations due to case mismatches

Logto integrations updates

1. WordPress integration guide: Added out-of-box WordPress plugin integration documentation to Logto console
2. Azure AD social connector enhancement: Added OAuth scopes field to @logto/connector-azuread

• Enables customization of requested user permissions
• Provides greater flexibility in access control

3. OIDC SSO connector authentication bug fixes: Removed client_id from token request body

• Resolves compatibility issues with OIDC providers like Okta
• Eliminates redundant client authentication method
  • Before: client_id included in both request body and authentication header
  • After: Uses authentication header only
• This OIDC SSO connector update improves compatibility with providers that enforce strict client authentication methods. By removing the redundant client_id from the request body while maintaining the authentication header, we ensure consistent behavior across different OIDC providers.