logto

Mark the Home component as async because it uses await getLogtoContext():

const Home = async () => {
  const { isAuthenticated, claims } = await getLogtoContext(logtoConfig);
  // ...
};

export default Home;

Then run npm run build again. The incorrect non-async example in the Logto Console guide was fixed by PR #9692; update Logto if the guide still shows const Home = () => {.

Logto Cloud now supports OAuth Client ID Metadata Documents. Configure the Cloudflare MCP gateway as follows:

1. Host a client metadata JSON file at a public HTTPS URL, for example https://example.com/logto-mcp-client.json:

{
  "client_name": "Cloudflare MCP Gateway",
  "redirect_uris": [
    "https://oauth-callbacks.cloudflareaccess.com/cdn-cgi/access/outbound-oauth-callback"
  ],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "scope": "openid",
  "token_endpoint_auth_method": "none"
}

2. In the Cloudflare MCP Server Portal OAuth configuration, set the client ID to the full URL of that metadata document.
3. Connect to https://mcp.logto.io again. Logto will fetch the document and accept the gateway callback listed in redirect_uris.

Verify support with:

curl https://auth.logto.io/oidc/.well-known/openid-configuration

The metadata should include "client_id_metadata_document_supported": true. Do not use the built-in mcp-client ID for Cloudflare because it is restricted to localhost redirect URIs.

This is fixed by Logto PR #9593. Upgrade to a release containing that fix. The bug occurs in packages experience/src/containers/VerificationCode/use-continue-flow-code-verification.ts: the link_social branch offers account linking without first calling isVerificationCodeEnabledForSignIn(type). The patched code only shows the link modal when the identifier can sign in with a verification code; otherwise it shows the normal "identifier already exists" message and returns the user to change it. As a temporary workaround on Logto 1.42.0, remove the conflicting phone secondary-identifier requirement, or enable phone verification-code sign-in. Note that phone verification-code sign-in cannot be enabled while PhoneVerificationCode is configured as an MFA factor, so it must be removed from MFA first.

Pass the theme authentication parameter with light or dark when initiating the Logto sign-in flow, e.g. extraParams: { theme: 'dark' }, or add theme=dark to the OIDC authorization URL. When dark mode is enabled in Logto, this parameter overrides the default/OS theme; if dark mode is disabled, the parameter is ignored. This support was added in PR #9645.

This occurs on Logto's unified sign-in/registration form. Before the code is verified, Logto cannot distinguish whether the email belongs to an existing sign-in account or a new registration, and rejecting it earlier could expose whether an account exists. The allowlist is still enforced after verification, so a disallowed email cannot complete registration.

To reject disallowed emails before a verification code is sent, use the explicit sign-up/register flow, which already performs the allowlist check before invoking the email connector. If the check is required on the unified sign-in path as well, upgrade to a release containing the PR fix(core): check the email allowlist before sending a sign-up sign-in code, or cherry-pick that change in a self-hosted build and rebuild Logto. After upgrading, verify the fix by submitting a non-allowlisted address: the verification-code request should fail immediately and no email should be sent.