MeshX v1.46.0

Highlights

• Ask AI works on your tenant. It reads your tenant's data and proposes changes. Nothing is applied until you confirm.
• Landing page CMS and demo chat. Edit the marketing site from the console. The demo chat collects leads only after the visitor agrees.
• Node.js 24 and React 19. The console and the apps move to React 19, and Node.js 24 is now the baseline for core.
• Stripe billing for Cloud. Subscription checkout, the billing portal, and usage metering.
• Post-quantum signing keys (preview). ML-DSA-65 OIDC signing keys, behind dev features.

Features

Ask AI

• Reads the tenant's sign-in experience, MFA settings, and members. Proposed writes wait for your confirmation.
• Chat is rebuilt on assistant-ui and styled like the landing demo chat.
• The tool loop runs as a LangGraph graph behind a dev flag.
• Can manage Kubo stacks.

Landing page

• CMS for the marketing site. The site is served at the root and the console at /console.
• The editor previews the whole page and runs the demo chat.
• Demo chat: a Cloudflare Turnstile check before each new session, conversations recorded in the admin tenant, and visitor consent before any lead is sent.
• Leads are filed as Kubo demo requests and listed on a Leads page in the admin console, with meeting brief downloads.
• Chat rate limits are shared across instances. Transcripts and unsent leads are deleted after 90 days.
• Language switcher in the top bar, plus a Try button with an animated popover.

Kubo workspaces

• Complete workspace UI.
• Stack deletion from the console and through Ask AI.

Billing (Cloud)

• Subscription checkout through Stripe, with paid checkouts applied to tenant subscriptions.
• Stripe billing portal, plus an enterprise billing portal route.
• Periodic usage metering and add-on SKUs.
• Production tenants get a Pro subscription.

Accounts and access

• Self-service personal access tokens in the Account API (ManageAccountSelf scope).
• Read-only tenant access: write controls are hidden for read-only members and the Management API has a read-only mode.
• MFA: first-factor establishment and MFA enrollment during sign-in and step-up.
• Multiple admins, mandatory console MFA, and hiding Logto branding no longer need a license.
• Rebranded to MeshX, with an Azure Communication Services email connector.
• Admin tenant: operators, and the first admin-tenant user gets the admin role on Cloud too.

Post-quantum signing (preview)

• ML-DSA-65 OIDC signing keys. Behind dev features; ML-DSA-65 is only advertised for ML-DSA tenants.

Fixes

• Landing chat: model calls time out, failed turns are answered in the visitor's language, and the visitor's message is kept when the model fails.
• Console: invitations (expiry dates, missing roles, per-invite requests), tenant member list, sign-out redirect, sidebar highlight, and the admin tenant label.
• MCP portal: asks the admin to sign in again when an upstream rejects sign-in.
• Retired signing keys no longer sign, for any key type.
• Custom UI zip upload in the tunnel no longer fails on upload.

Platform and dependencies

Runtime

• Node.js: core requires ^24.7.0 || ^26.0.0 and drops Node.js 22 from its engines range. Other packages accept ^22.14.0 || ^24.0.0 || ^26.0.0.
• pnpm engines accept ^11.0.0 as well.
• CI runs on Node.js 24.7 or later. The MCP portal image builds on Node.js 24.

React 19 (from 18.3)

• Console, experience, account, and both demo apps.
• react and react-dom 19.3, @types/react and @types/react-dom 19.3, @testing-library/react 16.3, react-modal 3.16.

Runtime dependencies

• @simplewebauthn/server 10 → 13
• nodemailer 9 → 10 (SMTP connector)
• @modelcontextprotocol/sdk 1.20.2 (added to core)
• @langchain/langgraph 0.2.74 (added to core)
• @assistant-ui/react 0.15.30 and @assistant-ui/react-markdown 0.14.23 (added to console)
• pdf-lib and pptxgenjs (added to core, for the meeting brief PDF)
• tinypool 2.1.2
• @silverhand/slonik 31 beta, @withtyped/server 0.14, jose 6.2, zod 3.24.3 (added to cloud)
• Removed: posthog-node (core), posthog-js (console), @inkeep/cxkit-react (console)

Build and dev tooling

• vitest and @vitest/coverage-v8 4.1
• @silverhand/eslint-config 6.0.1 and @silverhand/ts-config 6.0.0
• typescript 5.5, prettier 3.5, eslint 8.56, lint-staged 15
• @playwright/test 1.48 (console)
• sass 1.77.8 (root)
• tsup 8.5 and nock 14 (ACS email connector)

Security

• Vulnerable dependencies upgraded.
• OIDC type packages and pg-protocol pinned with workspace overrides.

For the full dependency diff, see the full changelog.

v1.45.0

Highlights

• Self-hosted license-based entitlements (Self-Hosted Pro): Unlock premium features on self-hosted Logto deployments with a license key—including team collaboration with Console members & email invitations, removing Logto branding, custom sign-in UI (Bring your UI) and CSP, higher SAML application limits, and tenant-wide Console MFA enforcement.
• Resource and scope query optimizations: GET /api/resources?includeScopes=true now matches scopes in linear time, fixing slowdowns and database parameter limit errors for tenants with large numbers of resources. The Management API also supports excludeManagementApis=true to prevent timeouts in Console permission pickers.

New features & enhancements

Self-hosted license entitlements (Self-Hosted Pro)

Self-hosted Logto deployments can now install and activate subscription licenses (such as Self-Hosted Pro) to unlock advanced capabilities while running entirely within their own infrastructure.

• Installing and managing licenses: Install or replace a license directly in Console under Tenant settings > License, or automate it via the Management API (PUT /api/systems/license and GET /api/systems/license). The installed key is verified offline using ES256 signatures against Logto's embedded public key.
• License status and grace period: View the current plan, environment (production or non-production), expiration date, and automatic weekly refresh status. If a license expires or cannot be refreshed, a 30-day grace period keeps features running while alerting admins with global warnings in Console before falling back to OSS defaults.
• Retrieve keys from Cloud Console: Users with an active self-hosted subscription can view their licenses and copy production and non-production keys directly from the account menu in Logto Cloud Console, without needing to provision a Cloud tenant.
• Unlocked entitlements:
  • Console members & invitations: Invite other administrators to manage the self-hosted deployment. Invitations are delivered by email using the default tenant's email connector with secure one-time account setup links.
  • Remove Logto branding: Hide "Powered by Logto" on the sign-in experience.
  • Custom sign-in UI and CSP: Upload custom sign-in UI bundles using your own storage, and customize Content Security Policy headers.
  • Expanded SAML applications: Increase the SAML application limit beyond open-source defaults.
  • Mandatory Console MFA: Enforce multi-factor authentication for all administrators accessing the Console.

See Self-hosted license for setup and details.

API resource query optimizations

• Linear-time scope matching: In GET /api/resources?includeScopes=true, matching scopes to API resources now runs in linear time using Map.groupBy and PostgreSQL array binding (= ANY(...)). This eliminates quadratic slowdowns and resolves failures on tenants with more than 65,535 resources (#9715).
• Exclude Management API resources: GET /api/resources now accepts an excludeManagementApis query parameter to filter out internal Logto Management API resources at the database level. Console permission pickers for third-party apps, dynamic apps, organization roles, and user roles now use this filter instead of loading every resource into the browser, preventing UI timeouts on resource-heavy tenants (#9716).

Bug fixes & stability

Documentation

• Next.js App Router guide: Updated the app/page.tsx example in the Next.js App Router quick start to declare Home as an async component, fixing TypeScript error TS1308 (#9692). Thanks to @timokoethe.

Contributors

Huge thanks to the community members whose work shipped in this release:

• @timokoethe - correct async home component in Next.js App Router guide (#9692) (first contribution)

Full Changelog: logto-io/logto@v1.44.0...v1.45.0

v1.44.0

Highlights

• MFA trusted devices: After completing MFA, users can trust their browser and skip repeated MFA prompts on it. Admins set the policy for the whole tenant, restrict it per organization, and manage devices from Console, Account Center, and the APIs.
• Keep your user IDs when migrating: User IDs can now be up to 128 characters, and self-hosted Logto accepts a custom id when creating a user, so IDs such as auth0|abc123 survive a migration. The Management API can also look up users by their external identity.
• Cap, a self-hosted CAPTCHA: Use Cap for bot protection where Cloudflare Turnstile and Google reCAPTCHA are unreachable or unreliable. reCAPTCHA Enterprise also gets a configurable score threshold.
• Authentication policies for SAML applications: Let a SAML application reuse an existing Logto session, require signed authentication requests, and get the actual authentication time in assertions.
• theme authentication parameter: Pass theme=light or theme=dark to keep the sign-in experience in sync with your app's own theme toggle.
• Refresh tokens for dynamic app clients: A new client compatibility setting for dynamic apps (CIMD) lets MCP clients such as ChatGPT and Codex receive refresh tokens, so users stop having to sign in again every time the access token expires. Applications registered in Logto are not affected.

New features & enhancements

MFA trusted devices

Users who complete MFA can now choose to trust their browser and skip repeated MFA prompts there.

• Tenant policy: Enable trusted devices in Console > Multi-factor authentication and set a trust duration from 1 to 365 days (default: 30). The policy is off by default.
• Organization restrictions: An organization can disallow trusted devices for its members. This only tightens the tenant policy.
• Trust this device page: After an eligible MFA verification or setup, users see a dedicated page at the end of sign-in or sign-up, where they can trust the browser for the configured duration or skip.
• Device management: Admins view and remove a user's trusted devices in Console > User management or through GET /api/users/{userId}/trusted-devices and DELETE /api/users/{userId}/trusted-devices/{trustedDeviceId}. Users manage their own devices in Account Center (field control: Off, Read-only, or Edit) or through the Account API at /api/my-account/trusted-devices with the urn:logto:scope:trusted_devices scope.
• Webhooks and audit logs: Subscribe to TrustedDevice.Created and TrustedDevice.Deleted webhooks. Audit logs record TrustedDevice.Created and TrustedDevice.Used.

A trusted device only fulfills the MFA step of a sign-in. It does not satisfy identity verification, account recovery, or other sensitive account operations. See MFA trusted devices.

Keep existing user IDs when migrating

• Longer user IDs: users.id and every column that references it were limited to 12 or 21 characters. They now accept up to 128 characters.
• Custom user ID on create (Logto OSS only): POST /api/users accepts an optional id of up to 128 characters (letters, numbers, and _ - . @ : + = |). Use it to preserve IDs such as auth0|abc123 or UUIDs when migrating from another identity provider. If the ID is taken, the request fails with user.id_already_in_use. Logto Cloud does not support this. See Keep existing user IDs.
• Look up users by external identity: GET /api/users accepts identityType, identityProvider, and identityId for exact lookup. Use identityType=social with a connector target (such as dingtalk), or identityType=sso with an enterprise SSO issuer, together with the user identifier issued by that provider. The identity filter combines with other search filters using AND logic. See Look up by external identity. Thanks to @JunWang666 (#9572).

Bot protection

Cap as a self-hosted CAPTCHA provider

Cap is an open-source, self-hosted proof-of-work CAPTCHA. It needs no third-party service, so bot protection keeps working in regions where Cloudflare Turnstile and Google reCAPTCHA are unreachable or unreliable.

1. Deploy a publicly reachable Cap Standalone instance and create a site key.
2. Go to Console > Security > CAPTCHA and add Cap with the instance endpoint, site key, and secret key. The same configuration is available through PUT /api/captcha-provider with type: "Cap".

While Cap is the CAPTCHA provider, the sign-in page's Content Security Policy allows the Cap instance and dynamic JavaScript evaluation, which Cap's instrumentation challenge requires. Thanks to @imJack6 for the request (#9404).

reCAPTCHA Enterprise score threshold

Set the minimum accepted score (0.0 to 1.0) for reCAPTCHA Enterprise in Console > Security > CAPTCHA to control how strict verification is. The threshold was previously fixed at 0.5. It applies to invisible mode. Checkbox mode is unaffected.

Authentication policies for SAML applications

• Session reuse: SAML applications still force fresh authentication by default. To let an application reuse an existing Logto session, turn off Always force authentication in the application settings, or set authnRequestConfig.forceAuthn to false through the SAML application Management API. The service provider can still require fresh authentication for a single sign-in with ForceAuthn="true".
• Actual authentication time: SAML assertions now report when the user actually authenticated.
• Signed authentication requests: Set authnRequestConfig.requireSignedAuthnRequests to true and provide the service provider's PEM-encoded RSA X.509 certificate in authnRequestConfig.signingCertificate. Both HTTP-POST and HTTP-Redirect signatures are verified, and the IdP metadata advertises the requirement. Unsigned requests remain accepted by default.

theme authentication parameter

Pass theme=light or theme=dark as an extra authentication parameter to render the sign-in experience in that theme instead of following the end user's OS setting. Applications with their own light/dark toggle can now keep Logto in sync.

The override lasts for the whole authentication flow, including page reloads, social and SSO callbacks, and the consent page. It is ignored when dark mode is disabled in the sign-in experience settings, and unsupported values are ignored.

Refresh tokens for dynamic app clients

This setting applies only to dynamic apps: clients that use an OAuth Client ID Metadata Document (CIMD) URL as their client_id. Applications registered in Logto are not affected.

MCP clients such as ChatGPT and Codex follow the MCP authorization spec, which only asks them to request the offline_access scope. They don't send prompt=consent, and without it Logto drops offline_access as OpenID Connect Core requires. These clients get no refresh token, so users have to sign in again whenever the access token expires.

Turn on Add consent prompt for offline access under Client compatibility in the dynamic app settings. Logto then adds consent to the prompt of dynamic app authorization requests that ask for offline_access without it. Requests with prompt=none are left unchanged. The setting is experimental and off by default, and audit logs show the added consent in prompt.

Management API SDK (@logto/api)

• Pagination iterator: paginate() returns a typed async iterator over paginated GET endpoints, following the Management API pagination headers.

  for await (const user of apiClient.paginate('/api/users')) {
    console.log(user);
  }

• Reliability:

  • Token requests reject redirects, support custom abort signals and a configurable 10-second timeout, and concurrent requests share one token fetch.
  • A rejected cached token is invalidated once, without fetching tokens over and over for permanent 401 responses.
  • Management API network requests get a configurable 10-second timeout while keeping per-request cancellation.
  • Scope mismatch warnings are emitted once per distinct scope, and token request failures keep their cause.

• Ergonomics:

  • Object-style Management API client configuration with a tenant ID, or an explicit base URL and API indicator.
  • Lowercase client methods such as .get() and .post(), with the uppercase methods still available.
  • Trailing slashes in custom base URLs are normalized.

Bug fixes & stability

Sign-in experience

• Browser auto-translation no longer blanks the page: When a browser auto-translated the sign-in page, React's DOM updates could fail and leave the user on a blank page mid sign-in. The experience is already localized per tenant, so the page now opts out of browser auto-translation with translate="no" and <meta name="google" content="notranslate">.
• Social account linking: When a required secondary identifier (such as a phone number) is already used by another account during social sign-up, the "link and continue" option now only appears if that identifier can sign in with a verification code. Previously, linking failed with user.sign_in_method_not_enabled and left the user stuck.

Enterprise SSO and OIDC

• **Trail...

v1.43.0

Sign-in Experience now supports es-MX (Spanish, Mexico).

For users whose language is Spanish (Mexico), phone inputs default to the Mexico country code (+52). This release also fixes list formatter placeholders and the remaining untranslated MFA message in the Spanish locales.

Security hardening

SSRF protection for webhooks and enterprise SSO

Outbound requests configured through the Management API are now blocked when they resolve to loopback, private, link-local, cloud metadata, or other special-use addresses.

Protection now covers:

• Webhook delivery, including POST /api/hooks/:id/test.
• OIDC enterprise SSO discovery, token, and userinfo requests.
• SAML identity-provider metadata fetching.
• Every redirect hop made by these requests.

DNS names are checked when the connection is established, so a hostname that resolves to a protected address is rejected like a literal IP address.

Token exchange validation

In addition to requiring first-party subject tokens, Logto now validates that a JWT presented as an access_token subject is actually an access token.

The JWT must contain:

• The RFC 9068 at+jwt type header.
• A client_id claim.

OIDC ID tokens and other JWTs signed by the tenant can no longer be substituted for an access token. Invalid subject tokens are rejected with invalid_grant.

Third-party Account API restrictions

Third-party applications can no longer mutate account data through the Account API or Verification API. Such requests now return:

403 auth.third_party_application_forbidden

First-party applications, including Account Center and Console, are unaffected.

The check fails closed for unresolved client identifiers. This includes deleted applications whose access tokens are still active and CIMD clients whose identifier is a metadata URL.

No read route received a new direct guard. However, the following reads require verification records created through guarded routes and are therefore no longer reachable by third-party applications:

• GET /api/my-account/grants
• GET /api/my-account/sessions
• GET /api/my-account/mfa-verifications/backup-codes

Suspended users cannot receive new tokens

Token issuance and userinfo now reject suspended users with invalid_grant, matching the existing behavior for deleted users.

This applies across refresh token, authorization code, device code, and token exchange flows, even if an earlier token or session revocation did not complete successfully.

Third-party application scopes are revalidated

Removing a user scope from a third-party application's consent configuration now affects existing grants as well as new authorization requests.

• Refresh token exchanges drop scopes that are no longer configured.
• Authorization requests resuming an existing grant fail with invalid_scope when appropriate.
• Organization token requests fail with insufficient_scope after the organizations scope is removed.
• Consent submission no longer grants a scope that was removed while the consent screen was open.

Identifier lockouts use normalized identifiers

Sentinel lockout counters now use the same normalized identifier form as account lookup:

• Email addresses are lower-cased.
• Phone numbers are canonicalized.
• Usernames are case-folded only when the tenant's username policy is case-insensitive.

This prevents alternate spellings of the same identifier from creating separate attempt buckets and weakening maxAttempts.

Manual unlock also clears equivalent spellings where they identify the same account. After upgrading, an existing lockout recorded under a non-canonical spelling may end early, but no user becomes more locked out than before.

Redirect validation

• Social landing-page redirect_to values must use http or https.
• Native callback links must use a custom application scheme.
• Stored callback links are checked again before the browser returns control to a native app.
• The unused Experience Springboard route has been removed to eliminate an untrusted redirect surface.

Bug fixes & stability

Authentication and authorization

• Revoking a user's third-party application authorization now invalidates only that application's tokens. The user's browser SSO session remains active.
• Elliptic Curve signing keys now advertise the algorithm matching their curve: P-256 uses ES256, P-384 uses ES384, and P-521 uses ES512.
• Switching from passkey sign-in to verification-code sign-in no longer prevents users from completing CAPTCHA.
• OIDC invalid_scope and insufficient_scope messages now show the rejected scope instead of raw {{error_description}} or {{scope}} placeholders.

Experience and localization

• Safari and other password managers can now suggest and save a strong password on set-password and reset-password screens using the correct account identifier.
• Accept-Language quality values with whitespace, such as en; q=0.7, are now parsed correctly. Invalid quality values fall back safely instead of producing NaN.
• Gmail custom allowlist and blocklist matching now treats gmail.com and googlemail.com as equivalent and ignores dots in the local part.
• Console now provides clearer examples, descriptions, and shorter placeholders for custom email rules.

Account Center and Management API

• Saving Account Center or sign-up settings now drops references to deleted custom profile fields instead of returning custom_profile_fields.entity_not_exists_with_names.
• Deleted fields remain removable from Console even when their permission control is Off.
• Management API relation endpoints now accept empty scope or role arrays as no-ops instead of returning a 500 error. This includes endpoints such as:
  • POST /applications/:applicationId/user-consent-scopes
  • POST /organizations/:id/users/:userId/roles
• Date validation now matches the complete input and rejects trailing characters after an otherwise valid date.

Webhook delivery

Webhook POST requests now retry up to three times when the endpoint returns an HTTP 5xx response, matching the documented delivery contract.

Because a retried event may be delivered more than once, webhook receivers should process events idempotently.

Connectors

Microsoft Azure AD

The Microsoft Azure AD connector now supports a disableEmailSync option.

By default, the connector continues to copy the Microsoft Graph mail attribute into the Logto user profile. Enable this option when the connector should authenticate the user without synchronizing that address, matching the existing control available for Azure OIDC enterprise SSO.

Self-hosting & OSS notes

• Action required — outbound request protection: If webhooks or enterprise SSO connectors intentionally access services on a private network, add the required IP addresses or CIDR ranges to SSRF_ALLOWED_ADDRESSES before upgrading:

  SSRF_ALLOWED_ADDRESSES=10.0.0.0/8,127.0.0.1
  

  Allowlisting only the required destinations is safer than disabling protection globally.

• Dynamic app compatibility: Configuring SSRF_ALLOWED_ADDRESSES disables CIMD so unauthenticated dynamic clients cannot use the allowlist to reach private services. Setting SSRF_PROTECTION_DISABLED=true also disables CIMD.

• Configuration compatibility: OIDC_PROVIDER_SSRF_PROTECTION_DISABLED remains supported as an alias for SSRF_PROTECTION_DISABLED. These variables apply only to self-hosted deployments.

• Script runtime limits: Custom JWT and Actions scripts must complete within 5 seconds, stay within the 128 MB worker memory budget, and return JSON-serializable values.

• Database migration required: This release ships new schema alterations and indexes. After upgrading, run the database alteration command (npm run alteration deploy in the @logto/cli/core image, or logto db alteration deploy) before starting the new version. See the upgrade guide.

Contributors

Huge thanks to the community members whose work shipped in this release:

• @arpitjain099 - complete-string date validation (#9266)
• @shuvamk - RFC-compliant Accept-Language quality parsing (#9338)
• @darcyYe - webhook retries for HTTP 5xx responses (#9410)

For the complete list of changes, see the full changelog.

v1.42.0

Highlights

• Custom domain verification files: Serve small text or JSON verification files from your active custom domain, so third-party services that verify domain ownership by file no longer need a separate host.
• Email access rules: A new email allowlist plus wildcard address and domain patterns give tenants precise control over which emails can sign up or be linked.
• Reset password magic links: The reset password landing page can now verify one-time-token magic links.
• OIDC provider upgraded to node-oidc-provider v9: Revoking an opaque access token now revokes the whole grant, and the RFC 8414 authorization server metadata endpoint is available.
• Hardened outbound requests: OIDC provider SSRF protection is now enabled by default — self-hosted deployments that reach private-network relying parties must opt out explicitly.

New features & enhancements

Custom domain verification files

Admins can now attach small verification files to an active custom domain from Console -> Tenant settings -> Domains, without Logto having to model any provider-specific behavior.

Each file has:

• A path that is either a root-level filename with an extension (for example /verify.txt) or a path under /.well-known/.
• A content type of text/plain or application/json. JSON content is validated on save.
• Content up to 16 KB.

Up to 10 files can be configured per domain, and paths must be unique. Logto serves exact GET and HEAD matches with the configured content type and response hardening; existing Logto routes always take precedence over a verification file at the same path. The Console experience is localized across all supported languages.

Email access rules: allowlist and wildcard patterns

The email blocklist policy is extended into a fuller set of email access rules.

• Custom email allowlist: Configure an allowlist of email addresses, domains, or wildcard patterns. When set, only matching emails are accepted for new sign-ups and newly linked emails, on both email registration and account email updates.
• Wildcard patterns: The allowlist and the blocklist both accept wildcard email address and domain patterns, such as foo*@example.com, *@example.com, and @*.example.com, alongside exact addresses (bar@example.com) and domains (@example.com).
• Conflict warnings: Console warns when allowlist entries also match a block rule, when an allowlist entry uses a plus sign while email subaddressing is blocked, and when the combined rules would let no new email through at all.

Both features are configured in Console -> Security -> Email blocklist. The matching and validation logic is now shared through reusable helpers in @logto/core-kit.

Reset password magic links

The Experience app now supports password reset flows that verify one-time-token magic links directly from the reset password landing page, in addition to verification codes.

Grant.LimitExceeded webhook event

When OIDC grants are evicted because an application exceeded its max allowed grants limit, Logto now fires a Grant.LimitExceeded webhook event, selectable in Console webhook settings like any other event.

The payload reports userId, applicationId, revokedGrantIds, maxAllowedGrants, and preRevocationActiveGrantCount. Dispatch is fire-and-forget: failures are recorded as TriggerHook.Grant.LimitExceeded audit log entries and never block the authentication response.

OIDC provider upgraded to node-oidc-provider v9

Security

• Revoking an opaque access token now also revokes every token under the same grant, including the refresh token. In v8, the refresh token stayed usable after revocation and could keep requesting new access tokens.

Updates

• The revocation endpoint now rejects JWT access tokens with unsupported_token_type, instead of returning a success response without actually revoking anything as in v8.
• Added the RFC 8414 authorization server metadata endpoint (/oidc/.well-known/oauth-authorization-server).
• Removed the redundant at_hash claim from ID tokens issued at the token endpoint.
• ID tokens no longer include the optional typ: "JWT" header. OpenID Connect defines ID tokens as JWTs and does not require clients to verify this header.

Action required for custom ID token verification

No action is required when using an official Logto SDK. If your integration performs custom ID token verification:

• If it requires the at_hash claim on ID tokens returned by the token endpoint, update it to allow the claim to be absent.
• If it requires the typ: "JWT" header, update it to allow the header to be absent.

HTTP framework upgraded to Koa 3

Logto now runs on Koa 3, the actively maintained release line that receives Koa's security fixes first. No behavior change is expected: all endpoints, OIDC flows, and API responses behave exactly as before.

Bug fixes & stability

Security and API hardening

• Internal application secrets are no longer exposed through Management APIs.
• The email blocklist policy is no longer returned in public sign-in experience responses.
• Retrieving stored third-party provider access tokens through the Account API now requires the identities user scope, matching the other social and enterprise SSO identity endpoints.
• Account API verification codes are no longer sent to blocked email addresses.
• Email and email domain validation now matches complete values and enforces stricter domain labels.

Experience and Account Center

• When a social or SSO registration flow is rejected by email access rules, acknowledging the error now returns the user to the Logto sign-in page instead of navigating back to the external identity provider.
• MFA is now enabled automatically after a user binds a factor through the Account APIs.

Data integrity and storage

• Creating a new email or SMS connector now runs the insert and the cleanup of old connectors in a single database transaction. Previously a crash between the two statements could leave duplicate connectors behind.
• Redis cluster credentials are now percent-decoded, so connections succeed when the username or password contains URL-reserved characters.
• TLS is now correctly enabled for Redis cluster connections that use the rediss protocol.

Connectors

• jose v6: The Apple, Google, OAuth, and OIDC connectors now use jose 6, which runs on the Web Crypto API instead of Node's crypto module. Token signing and ID token verification behave exactly as before.
• GitLab: Removed the unused jose dependency, so installing the connector no longer pulls in a package it never imported.
• Aliyun SMS: Hong Kong phone numbers are now treated as overseas numbers.
• Aliyun SMS authentication service (MAS): The signature is now entered as free text instead of a dropdown, so it keeps working if Aliyun rotates signatures again.

Self-hosting & OSS notes

• Action required — OIDC provider SSRF protection: Outbound request security is strengthened and SSRF protection is now enabled by default. Self-hosted deployments that need to reach trusted relying-party endpoints on private networks must set OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true before starting Logto; otherwise leave the variable unset.
• Database migration required: This release ships schema alterations (custom domain verification files, plus internal indexes and tables). After upgrading, run the database alteration command (npm run alteration deploy in the @logto/cli/core image, or logto db alteration deploy) before starting the new version. See the upgrade guide.
• Custom ID token verification: See the node-oidc-provider v9 section above for the at_hash and typ header changes.

Contributors

Huge thanks to the community members whose work shipped in this release:

• @Kathircpe - Grant.LimitExceeded webhook event (#9230) and transactional passwordless connector replacement (#9277)
• @d4nyll - Redis cluster credential decoding (#9145) and rediss TLS fix (#9144)
• @sjh9714 - Aliyun SMS Hong Kong number handling (#9111)
• @CertStone - free-text Aliyun SMS MAS signature (#9228)

For the complete list of changes, see the full changelog.

v1.41.0

Highlights

• App-level access control: Restrict application access by user, user role, organization, or organization role.
• Password expiration policy: Enforce password rotation per tenant and let admins manually expire a user's password.
• Account Center upgrades: Sessions, profile, avatar upload, and independent passkey controls are now available.

New features & enhancements

App-level access control

Admins can now restrict who can access an application. Access rules support:

• User IDs
• User roles
• Organizations
• Organization roles

When a user does not match the configured rules, Logto blocks the sign-in or application access flow with an access denied page.

Documentation: https://docs.logto.io/integrate-logto/app-level-access-control

Password expiration policy

Console now supports a per-tenant password expiration policy under Security -> Password policy.

Admins can:

• Enable password expiration.
• Configure how many days a password remains valid.
• Manually expire a specific user's password from the user details page.

When a password expires, the user must reset it through the configured recovery method before password sign-in can continue. SSO and passkey sign-ins are not affected.

Legacy users without a recorded password-change time are anchored to the time the policy is enabled, so they receive a full valid period instead of being expired immediately.

Account Center

Account Center now includes:

• Session management for reviewing active sessions and connected third-party applications.
• Profile management and avatar upload.
• Avatar upload support during collect-profile sign-up.
• Independent passkey controls separate from MFA.
• User control for passkey sign-in prompt preference.

The Account Center profile page, custom profile fields at sign-up, and avatar upload endpoints are available as part of the out-of-the-box profile experience.

Username policy

Operators can configure tenant-level username rules from Console -> Sign-in experience -> Sign-up and sign-in -> Advanced options.

The policy covers case sensitivity, length bounds, and allowed character types. It is enforced on end-user username writes in sign-up, profile fulfillment, Account Center, and Account API.

Switching to case-insensitive usernames is guarded: Logto detects existing usernames that differ only by case and blocks the change until conflicts are resolved.

The OIDC preferred_username claim now falls back to the user's username when profile.preferredUsername is unset.

Verification-code and message send controls

Admins can configure verification-code expiration duration and maximum retry attempts in Console Security settings.

Logto also adds a system-level per-recipient send rate limit across email/SMS verification and invitation send paths, including Experience, MFA, Account API, Management API, organization invitations, and the legacy interaction API.

When a send is throttled, Logto emits a Message.RateLimited webhook event, now selectable in Console webhook settings. Verification-code delivery to unknown recipients is suppressed when registration is disabled to reduce account enumeration risk.

JWT customizer organization context

For organization API resource tokens, the access token JWT customizer now receives context.organization with the target organization's id, name, description, and customData.

This lets scripts attach per-organization claims without embedding every organization mapping into every token.

API improvements

POST /api/applications/:applicationId/roles is now idempotent. Role IDs that are already attached to the application are ignored instead of returning 422 application.role_exists.

The endpoint now returns 201 with { roleIds, addedRoleIds }, matching the user role assignment API shape.

Organization role creation with initial scopes is now transactional, so invalid scope IDs no longer leave partially created roles behind.

Bug fixes & stability

Security and protocol hardening

• SAML IdP auto-submit forms now escape HTML attribute values and reject non-HTTP(S) action URLs.
• samlify is upgraded to ^2.13.0, improving XML escaping in generated SAML assertions.
• TOTP MFA verification now rejects replayed codes from the same or older time-step counter.
• OIDC request bodies containing null bytes now return 400 invalid_request, and audit log payloads strip null bytes before insertion.
• Email subaddressing blocklist checks no longer build regular expressions from user-controlled input.
• Logto Tunnel prevents static file requests from reading outside the configured experience path.

Experience and Account Center

• Tenant theme, platform, and brand color are applied before hydration to reduce theme flash in sign-in experience and Account Center.
• Hosted sign-in experience custom CSS is now inlined into server-rendered HTML to prevent a flash of built-in styles.
• Account Center step-up verification is restricted to user permission verification records.
• Social identities can be linked in Account Center without password, email, or phone verification when the user has no legacy security verification methods.
• Console username editing now redirects to Account Center so the required verification flow can complete.

Compatibility and storage

• Older Safari and iOS 15 no longer crash on startup because of unsupported regex lookbehind syntax.
• OIDC enterprise connectors can fetch discovery configuration from providers that reject JSON-only response negotiation.
• Custom UI asset Azure Blob transport failures now map to retryable storage download errors, and upload timeout handling is improved.

Connectors

• New - SMTP2GO email connector: Send transactional auth emails through the SMTP2GO send API.
• QQ connector: Supports social identity verification with stored redirect URI.
• SAML connector: Upgrades samlify and adapts to its stricter return types.
• Connector Kit: Exports shared SMTP mailbox parsing and formatting utilities, now also used by MailJunky.

Self-hosting & OSS notes

• CASE_SENSITIVE_USERNAME deprecation: The environment variable still works as a runtime override, but username case sensitivity should now be configured per tenant through the username policy. It is deprecated and slated for removal in the next major version.

Contributors

Huge thanks to the community members whose work shipped in this release:

• @tevass - password expiration policy (#8643)
• @mrprofessor - idempotent application role assignment API (#8901)
• @darcyYe - custom CSS first-paint fix for hosted sign-in experience (#9017)

For the complete list of changes, see the full changelog.

v1.40.1

Patch Changes

This is a patch release to correct a missed version bump for @logto/core-kit, again...

In v1.40.0, new @logto/core-kit exports were introduced for Custom UI CSP utilities and protected app additional scopes, but the changeset did not make it into the release. As a result, @logto/core-kit stayed at 2.9.0 while downstream packages were already expecting the new exports. JavaScript package graphs are forgiving about many things; missing exports are not one of them.

v1.40.1 publishes @logto/core-kit@2.10.0 so the released packages are back in sync.

@logto/core-kit@2.10.0

• Add custom CSP utility methods

v1.40.0

Highlights

• Audit logs time-range picker: Scope the audit log to a bounded time window (preset windows plus a custom range), backed by a server-side count cap that keeps large-volume tenants responsive.
• Organization membership webhook deltas: Organization.Membership.Updated now reports exactly which users and applications were added or removed.
• Faster organizations at scale: New secondary indexes and query rewrites speed up membership listing and per-user role lookups on large tenants.
• Air-gapped & self-hosted friendliness: A new --dapc install/seed flag and DB-direct admin signing keys remove outbound-network and DNS friction for OSS deployments.
• New connectors: MailJunky email, SMSBao SMS, and the Aliyun SMS authentication service connector, plus Aliyun Direct Mail regions and richer WeCom profiles.

New features & enhancements

Audit logs time-range picker

• The Console audit logs page now ships a time-range picker with a default window of the last 7 days. Presets cover Last 1 hour / Last 24 hours / Last 7 days / Last 30 days, plus a custom date range.
• The API gains start_time and end_time query parameters on GET /api/logs and GET /api/hooks/{id}/recent-logs (exclusive bounds, unix milliseconds). On GET /api/hooks/{id}/recent-logs, supplying either bound replaces the default 24-hour lower bound.
• A new enableCap=true query parameter on GET /api/logs and GET /api/hooks/{id}/recent-logs short-circuits the count query at ~10,000 rows to reduce statement_timeout risk on very large log volumes. Capped responses return a Total-Number-Is-Capped: true header, and the Console renders a Prev/Next layout in that case. Default behavior (without the param) is unchanged.

Organization membership webhook deltas

• The Organization.Membership.Updated webhook payload is enriched with explicit delta fields: addedUserIds / removedUserIds and addedApplicationIds / removedApplicationIds across the user and application membership endpoints, plus addedUserIds on invitation accept and just-in-time provisioning (email-domain JIT and enterprise SSO JIT).
• Empty deltas are omitted; each delta array is capped at 5000 entries (reconcile bulk changes via GET /organizations/:id/users or .../applications). This is an additive, non-breaking change — see the webhook reference.

Account API: sessions isCurrent

• GET /api/my-account/sessions now returns isCurrent: boolean on every entry, so session-management UIs can mark the "This device" entry and avoid revoking the caller's own session. The admin user-sessions endpoints are unchanged.

Performance for large organizations

• GET /organizations/:id/users is rewritten to aggregate roles via a LATERAL subquery, so LIMIT prunes the user set before role lookups instead of materializing the full members × roles join on every page.
• New secondary indexes speed up reverse lookups: organization_user_relations (tenant_id, user_id) (hit on every sign-in and the membership middleware) and organization_role_user_relations (tenant_id, organization_id, user_id) (hit by getUserScopes and per-user role joins).
• PUT /organizations/:id/users now uses a new delta-based replaceWithDelta() query that writes only the rows that actually changed, preserving role assignments for members whose membership survives the update.

OpenAPI: accurate arbitrary-object types

• Arbitrary JSON object schemas now declare additionalProperties: true in the OpenAPI document, so generated TypeScript clients (e.g. @logto/api) type fields such as customData as { [key: string]: unknown } instead of Record<string, never>.

Bug fixes & stability

Experience

• Terms agreement on sign-in-to-registration: When the agreement policy is ManualRegistrationOnly, signing in with an unregistered email or phone and then confirming "create a new account" now prompts the terms agreement before the account is created, matching the dedicated registration and social/SSO flows.

Account Center

• Initial password setup: Users with no password, no primary email, and no primary phone can now set their initial password without a verification record through the Account API.
• Silent re-authentication: On a user-info error (e.g. a stale access token after switching users in the same browser), Account Center re-authenticates with prompt=none instead of forcing the login screen, falling back to prompt=login only when no valid session exists.
• Expired sessions: Expired Account Center sessions now redirect cleanly without flashing the manual sign-in error.
• Social linking callback: The social linking callback is rendered through React Router so connectorId is read correctly, fixing a spurious "social sign-in method is not enabled" error.
• 2-step verification label: Clarified the Account Center 2-step verification toggle label.

Internationalization

• Corrected the Chinese translation of "Passkey" in the MFA experience phrases.

Self-hosting & OSS notes

• Air-gapped admin setup (--dapc): The install and db seed commands accept a new --dapc flag (alias --disable-admin-pwned-password-check). It seeds the admin password policy with the Have I Been Pwned breach check disabled, so the first admin sign-up no longer hangs when api.pwnedpasswords.com is unreachable.
• Admin signing keys read from the database: OSS deployments now read the admin tenant signing keys directly from the database, removing the extra host/DNS mappings that previously let the container fetch its own admin tenant OIDC configuration through the external endpoint.
• Database migration required: This release ships schema alterations (the new organization-relation indexes and additional internal columns). After upgrading, run the database alteration command (npm run alteration deploy in the @logto/cli/core image, or logto db alteration deploy) before starting the new version. See the upgrade guide.

Connectors

• New — MailJunky email connector: Send transactional auth emails via the MailJunky send API.
• New — SMSBao SMS connector: Domestic SMS verification flows via SMSBao.
• New — Aliyun SMS authentication service connector: Adds the Aliyun SMS authentication (MAS) service.
• Aliyun Direct Mail regions: The Aliyun DM connector now supports configuring the Direct Mail region.
• WeCom: Fetches richer user profile details via additional API calls.
• SMTP: The auth config may now omit user and pass, so relays that authorize by source (e.g. IP/VLAN) can be configured without forging credentials.
• Connector Kit: Tightened email branding URL detection to avoid false positives on dotted abbreviations.

Contributors

Huge thanks to the community members whose work shipped in this release:

• @devadarshh — MailJunky email connector (#8638)
• @wintbiit — SMSBao SMS connector (#8871)
• @CertStone — Aliyun SMS authentication service connector (#8385)
• @liyujun-dev — WeCom profile enrichment (#8191)
• @aayushbaluni — email URL detection fix (#8747)
• @rotempasharel1 — Chinese Passkey translation fix (#8870)
• @taka-guevara — Account Center silent re-authentication (#8785)
• @darcyYe — --dapc air-gapped admin seed flag (#8859)
• @chiche84 — original organization membership webhook delta proposal (#8752)

For the complete list of changes, see the full changelog.

v1.39.0

Highlights

• Private signing key rotation grace period: Logto now supports a grace period when rotating private signing keys, helping clients refresh cached JWKS without downtime.
• Custom JWT script error handling: Access token and client credentials JWT customization can now block token issuance when scripts fail.
• Account Center security page: End users can now manage social account linking, MFA, and account deletion from the Account Center.
• WhatsApp connector: A new WhatsApp SMS connector is available through the Meta Cloud API.
• Security and compatibility fixes: Forgot-password verification responses are now unified to reduce account enumeration risk, and in-app browser social / SSO redirects are more resilient.

New features & enhancements

Private signing key rotation grace period

Logto now supports a grace period during private signing key rotation.

This can be configured through:

• The PRIVATE_KEY_ROTATION_GRACE_PERIOD environment variable.
• The --gracePeriod CLI option.

During the grace period:

• The newly generated signing key is marked as Next.
• The existing signing key remains active as Current.
• Clients have time to refresh cached JWKS before the new key becomes active.

After the grace period ends:

• The new private signing key transitions to Current.
• The old signing key is marked as Previous.

This provides a smoother key rotation process and helps avoid authentication failures caused by stale JWKS caches.

Documentation: https://docs.logto.io/logto-oss/using-cli/rotate-signing-keys

Custom JWT script error handling

Logto now supports configurable error handling for custom JWT scripts used in access token and client credentials flows.

Included changes:

• Custom JWT scripts can now block token issuance when execution fails.
• api.denyAccess() is preserved as an access_denied response.
• Other blocking-mode script failures are returned as localized invalid_request responses.
• Console adds a dedicated Error handling tab for configuring the behavior.
• Newly created scripts default blockIssuanceOnError to enabled.
• Existing scripts without a saved value keep the legacy disabled behavior.
• Related Console guidance, phrases, schemas, and integration coverage are updated.

This helps developers choose whether token customization failures should fail open or fail closed depending on their security requirements.

Account Center security page

This release adds a new security page to the out-of-the-box Account Center.

End users can now manage account security from /account/security, including:

• Social account linking and unlinking.
• MFA 2-step verification.
• Account deletion.

Console support:

• The sign-in experience Account Center settings now expose the delete-account URL field.
• Console surfaces Account Center and social prebuilt UI entries.

WhatsApp connector via Meta Cloud API

A new WhatsApp connector is added for sending messages through the Meta Cloud API.

This enables WhatsApp-based SMS / verification-code delivery scenarios using the official Meta Cloud API integration.

Organization assignment API response bodies

Organization user and role assignment APIs now return response bodies.

Updated endpoints:

• POST /organizations/:id/users now returns { userIds: string[] }, echoing the user IDs sent in the request.
• POST /organizations/:id/users/:userId/roles now returns { organizationRoleIds: string[] }, containing the final deduplicated role IDs assigned to the user, including IDs resolved from provided role names.

Console theme token update

Console themes now include the missing --color-overlay-primary-subtle token for both light and dark modes.

Bug fixes & stability

Forgot-password verification enumeration protection

Forgot-password verification now returns a unified verification_code.code_mismatch error.

This prevents the flow from exposing whether an email or phone number exists through different error responses.

Social and SSO redirects in in-app browsers

Improved social and SSO redirect reliability in in-app browsers such as Instagram, Facebook, and LINE.

Some in-app browsers open OAuth identity provider pages in a new WebView, which can cause sessionStorage to be lost after redirecting back.

This release adds a localStorage fallback:

• Redirect state is still stored in sessionStorage.
• A fallback redirect context bundle is also stored in localStorage.
• On callback, Logto restores state from localStorage if sessionStorage is missing.
• Fallback entries are consumed on read and automatically swept after 10 minutes.
• If both storage locations are empty, the user sees an error toast.

Verification code connector request IP

Fixed an issue where the request IP was not passed to connectors when sending verification codes.

This allows connectors to receive the correct request context for verification-code delivery.

Contributors

Thanks to everyone who contributed to this release:

• @konlanx in #8626
• @makisekuris in #8616
• @MrMardel in #8458

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