logto

Highlights

• OIDC step-up authentication: Apps can request acr_values and max_age and read acr, amr, and auth_time from tokens. Account Center uses it to require a recent sign-in before sensitive changes.
• Sign-In with Ethereum: A new Ethereum Wallet social connector lets users sign in with an EVM wallet.
• Keep the iOS "Save Password" prompt: The confirm_redirect_policy sign-in parameter shows a "Continue" page before returning to the app after the user enters a password.
• Personal access tokens in Account Center: Users can create, rename, and revoke their own personal access tokens.
• GeeTest CAPTCHA: Use GeeTest CAPTCHA v4 for bot protection, which suits sign-in experiences targeting mainland China.
• Static attributes for SAML applications: Send fixed attribute values in every SAML assertion.
• Security fixes, one needing admin action: This release includes security fixes for MFA, social and enterprise sign-in, the Account API, and Logto Tunnel. Standard OAuth 2.0 and Microsoft Azure AD social connectors need a settings review after upgrading. See Security hardening below.

New features & enhancements

OIDC step-up authentication

OIDC clients can now ask for a recent or stronger sign-in:

• Request: Pass acr_values and max_age in the authorization request. Logto advertises the supported ACR values in the discovery document.
• Result: acr, amr, and auth_time are returned in ID tokens, access tokens, and introspection responses.
• Account Center: The built-in Account Center now authorizes sensitive Account API operations with a fresh first-party urn:logto:acr:1fa access token instead of a separate verification record. When the sign-in is not recent enough, the Account API answers with an RFC 9470 step-up challenge.
• Recent authentication window: Set how recent the sign-in must be in Console > Sign-in experience > Account center > Recent authentication (10 minutes by default). A client can still request a shorter window with max_age.
• Compatibility: Apps that call the Account API directly can still use a verification record ID for sensitive operations.

See Step-up authentication.

Sign-In with Ethereum

Admins can enable the new Ethereum Wallet social connector (@logto/connector-siwe). Users with an injected EIP-1193 wallet sign a one-time SIWE (EIP-4361) message without leaving the sign-in page. A single address works across supported EVM chains, and admins can restrict the allowed chain IDs.

Keep the iOS "Save Password" prompt

On iOS, ASWebAuthenticationSession closes as soon as it sees the app's callback URL, which dismisses the system "Save Password" prompt right after the user signs in with a password.

Pass confirm_redirect_policy=password in the authorization request to show a page that returns to the app only when the user selects "Continue". The page appears after the user enters a password in the sign-in experience: password sign-in, password registration, setting a password, or a step-up password verification.

Without the parameter, Logto redirects back to the app right away. Third-party applications ignore it. The Swift integration guide in Console shows how to use it. See Keep the iOS Save Password prompt.

Personal access tokens in Account Center

When the tenant enables the personal access token field in Account Center, users can create, rename, and revoke personal access tokens on the Account Center Security page. Each token is shown only once at creation and expires within 365 days.

The same operations are available through the Account API under /api/my-account/personal-access-tokens, with the new urn:logto:scope:personal_access_tokens scope (UserScope.PersonalAccessTokens in @logto/core-kit).

GeeTest CAPTCHA

GeeTest CAPTCHA v4 is now available as a CAPTCHA provider. Its adaptive challenges are localized, which suits sign-in experiences targeting mainland China, where Google reCAPTCHA is often unreachable.

• Create a CAPTCHA v4 event in the GeeTest dashboard.
• Go to Console > Security > CAPTCHA and add GeeTest with its CAPTCHA ID and CAPTCHA key. The same configuration is available through PUT /api/captcha-provider with type: "Geetest".

While GeeTest is the CAPTCHA provider, the sign-in page's Content Security Policy allows GeeTest's SDK, API, and static hosts.

access_denied when sign-in is cancelled

• Consent page: Cancelling the built-in consent page now ends the interaction with access_denied and returns the user to the client application with the original state and iss.
• Direct sign-in: A failed direct sign-in returns to the client the same way, instead of falling back to the hosted sign-in page.
• Custom sign-in experiences: End the current interaction with the same error through POST /api/experience/abort, with an optional reason that becomes error_description. GET /api/experience/interaction/direct-sign-in returns the direct_sign_in value of the current authorization request, so a custom experience can tell a direct sign-in from a hosted one before the interaction is initialized.

User management

• Require MFA setup for a user: Turn on Require MFA setup on the user details page in Console, or set mfa.required to true through the Management API. The user must set up MFA on their next sign-in and cannot skip it, regardless of the organization-level MFA policy.
• Unlock a user: A new unlock action on the user details page clears sign-in and security verification lockouts keyed on the user's ID, primary email, primary phone, and username, so admins don't need to know which identifier triggered the lockout.
• SHA-crypt legacy password hashes: Import users with SHA-crypt hashes ($5$ and $6$, as used by Linux, passlib, PHP, and others) by setting the password algorithm to Legacy and passing the complete stored crypt string as the password digest.

Static attributes for SAML applications

SAML applications can define fixed attribute names and values that are sent in every assertion alongside the mapped user attributes, for service providers that require constant values such as an account or site ID.

• Console: Use the Static attributes section on the SAML application's attribute mapping tab.
• Management API: Set staticAttributes with POST /api/saml-applications or PATCH /api/saml-applications/{id}.

Attribute names may contain letters, digits, and _.:/#@-. They must not conflict with each other or with the user attribute names in the assertion, including names that differ only in case or separators, such as site_id and siteId.

Cross-Origin-Opener-Policy for Bring your UI

Tenants with Bring your UI can choose same-origin-allow-popups or same-origin under Console > Sign-in experience > Branding > Bring your UI, or set crossOriginOpenerPolicy with the sign-in experience Management API. The header is sent on the hosted sign-in pages while custom UI assets are served. The default, unsafe-none, sends no header, so apps that open the sign-in page in a popup keep working.

login_hint for Account Center

Add login_hint to any Account Center URL, for example https://auth.foo.com/account/security?login_hint=foo@example.com, to pre-fill the identifier on the sign-in page when the user needs to sign in. The hint only pre-fills the field, so users can still sign in with a different identifier.

Management API and webhooks

• Search users by custom data: GET /api/users accepts a repeatable customData query parameter that matches users whose custom data contains the given JSON object, for example customData={"customId":114514}. Repeated values are combined with OR, and the condition combines with other user filters using AND.
• Find organizations by just-in-time provisioning domain: GET /api/organizations accepts a jitEmailDomain query parameter that returns, with pagination, the organizations a user with this email domain would be provisioned into. It combines with q and pagination like the other filters.
• hasPassword for organization members: GET /api/organizations/:id/users now includes whether each member has a password set, matching the user list and user detail responses.
• Webhook deliveryId: Every webhook payload now carries a deliveryId. It is unique per hook and event and stays the same across retries of the same request, so a receiver can process each delivery exactly once. It is also the ID of the audit log entry that records the delivery: open it from the webhook's recent requests in Console, or fetch it with GET /api/logs/:id. The "test webhook" payload carries one too.

Security hardening

Action required: email sync for OAuth 2.0 and Microsoft Azure AD connectors

The standard OAuth 2.0 social connector (@logto/connector-oauth 1.8.0) adds a Disable Email Sync switch (disableEmailSync), matching the one the Microsoft Azure AD connector has offered since Logto 1.43.0.

Upgrading alone does not change how existing connectors behave. The switch is off by default, so these connectors keep syncing the email address returned by the provider to the user profile. The standard OAuth 2.0 protocol carries no verification state for an email address, so the mapped email value is taken at face value.

After upgrading, review every standard OAuth 2.0 and Microsoft Azure AD social connector. Turn on Disable Email Sync when the provider does not verify that users own the email addresses it returns. The address stays available in rawData.

Sign in with Apple

The Apple connector (@logto/connector-apple 1.6.11) now takes the user's email only from the Apple ID token, and recognizes email_verified whether Apple sends it as true or "true". When Apple marks the email as unverified, no email is returned. The user's name still comes from the details Apple sends on the first authorization.