Clerk Changelog

Jul 28

Hosted authentication for Expo, iOS, and Android

Category: SDK
Published: Jul 28

Let users sign in and sign up through the browser with Account Portal, Clerk’s hosted authentication pages

Clerk's mobile SDKs can now hand the entire sign-in and sign-up flow to Account Portal, Clerk's hosted authentication pages. A single method call opens the browser, the user authenticates on your Account Portal, and the created session is activated back in your app.

Because the flow runs through Account Portal, every authentication method enabled on your instance works without building native UI for it: email codes, passwords, social providers, enterprise SSO, and MFA all come along automatically, styled with your Account Portal branding.

Expo

import { useHostedAuth } from '@clerk/expo/hosted-auth'

const { startHostedAuth } = useHostedAuth()

await startHostedAuth()

iOS

try await clerk.auth.startHostedAuth()

Android

scope.launch {
  Clerk.auth.startHostedAuth()
}

Hosted authentication is available in @clerk/expo 4.1.0, the Clerk iOS SDK 1.3.5, and the Clerk Android SDK 1.0.37. See the mobile hosted authentication guide to get started.

Jul 27

Composable UserProfile and OrganizationProfile components

Category: SDK
Published: Jul 27

Build your own profile pages from Clerk’s building blocks, now available as an experimental API.

We’re shipping an experimental API that breaks <UserProfile /> and <OrganizationProfile /> into composable building blocks. Instead of mounting the whole component, you can assemble a profile page from the exact panels and sections you want, in the order you want them.

The building blocks live in the @clerk/ui package, which isn’t included with your Clerk SDK — install it as a direct dependency:

terminal

npm install @clerk/ui

Render the built-in panels

Wrap the building blocks in a provider and drop in a panel to render the same content Clerk renders today:

import {
  UserProfileProvider,
  UserProfileAccountPanel,
  UserProfileSecurityPanel,
} from '@clerk/ui/experimental'

export default function Page() {
  return (
    <UserProfileProvider>
      <UserProfileAccountPanel />
      <UserProfileSecurityPanel />
    </UserProfileProvider>
  )
}

Compose your own sections

Pass sections as children to a panel to pick and reorder only the pieces you need:

import {
  UserProfileProvider,
  UserProfileAccountPanel,
  UserProfileProfileSection,
  UserProfileEmailSection,
  UserProfilePhoneSection,
} from '@clerk/ui/experimental'

export default function Page() {
  return (
    <UserProfileProvider>
      <UserProfileAccountPanel>
        <UserProfileProfileSection />
        <UserProfileEmailSection />
        <UserProfilePhoneSection />
      </UserProfileAccountPanel>
    </UserProfileProvider>
  )
}

The same pattern applies to organizations with OrganizationProfileProvider, its panels (OrganizationProfileGeneralPanel, OrganizationProfileMembersPanel, and more), and their sections.

Experimental

This API is exported from @clerk/ui/experimental and is not covered by semantic versioning. The set of components, their names, and their props may change in any release while we gather feedback. We’d love to hear how you’re using it.

Jul 22

Connect your AI tools to Clerk MCP with one command

Category: Product
Published: Jul 22

clerk mcp install registers the Clerk MCP server in ten AI clients, including Claude Code, Cursor, and VS Code, with a built-in bridge and no manual config required.

Clerk's MCP server gives your AI agents up-to-date Clerk SDK snippets and implementation patterns. Until now, connecting it meant editing a different config file for every client. The latest Clerk CLI release adds a clerk mcp command group that handles the whole thing:

clerk mcp install

Ten clients, one command

clerk mcp install detects the AI clients on your machine and registers the Clerk MCP server in each one you pick from an interactive list. It supports Claude Code, Cursor, GitHub Copilot (VS Code), Windsurf, Gemini CLI, Codex, opencode, OpenClaw, Warp, and Hermes Agent.

Entries are registered user-globally, so the server is available in every project. Where a client ships a usable non-interactive registration command (like claude mcp add or codex mcp add), Clerk delegates to it so the client keeps owning its config format, and writes config files directly for the rest. Re-running install always converges: whatever is already sitting under the entry name is replaced, so there's no conflict state to untangle.

# Skip the prompt: target specific clients, or all of them
clerk mcp install --client claude --client cursor
clerk mcp install --all

clerk mcp list shows every Clerk entry the CLI has registered across your clients, and clerk mcp uninstall removes them, prompting only with the clients that actually have one.

A built-in bridge replaces `npx mcp-remote`

Instead of pointing each editor at a remote URL through npx mcp-remote, every client is configured to launch the same built-in bridge — clerk mcp run — expressed in that client's own config format ({ "command": "clerk", "args": ["mcp", "run"] } for most). clerk mcp run is a stdio↔Streamable-HTTP bridge built into the CLI, so there's no npx dependency, and updating the CLI updates the bridge everywhere at once with no re-install needed.

`clerk doctor` checks your connection

clerk doctor now probes your configured Clerk MCP server with a real initialize handshake, so you can tell the difference between "not installed", "installed but unreachable", and "working" at a glance.

Built for agents

Like every CLI command, clerk mcp respects the agent contract: non-TTY runs never prompt and emit JSON automatically, per-client failures are reported structurally in a failures array instead of aborting the run, and every registration-blocking error carries a stable code plus a docsUrl pointing at the manual setup instructions as a fallback.

Get started

Update to the latest CLI and connect your clients:

clerk update
clerk mcp install

See the CLI docs for the full command reference, or the Clerk MCP server docs for manual per-client setup.

Jul 22

Configurable default OAuth scopes

Category: Product
Published: Jul 22

Default OAuth scopes for dynamic client registration are now configurable.

You can now configure default OAuth scopes for dynamic client registration using the OAuth applications settings in the Clerk Dashboard, or the Backend API.

This helps when OAuth clients such as ChatGPT or Claude don't include the scope parameter in their registration request. A client may then request more scopes than it was dynamically registered with, resulting in an invalid_scope error. Setting default scopes helps Clerk users smooth over this commonly reported error when popular clients authenticate with their MCP servers.

Configurable default scopes give you some control over the access requested by clients that omit the parameter, which may vary per-client implementation. Clerk doesn't override a scope value that a client provides.

See the OAuth configuration guide for setup instructions.

Jul 16

Deprecating CBC cipher suites

Category: Security
Published: Jul 16

Starting January 18, 2027, Clerk will phase out CBC-mode SSL/TLS cipher suites on Clerk-managed subdomains as certificates rotate. Here's what's changing and why.

Beginning January 18, 2027, Clerk will stop supporting CBC-mode SSL/TLS cipher suites on Clerk-managed subdomains, including clerk.example.com (Frontend API) and accounts.example.com (Account Portal). This is a breaking change for clients that can only negotiate a CBC cipher, but most applications will not be affected, since modern clients already negotiate stronger ciphers.

The change rolls out as certificates are renewed. Clerk certificates are valid for 90 days, so every affected subdomain will have moved to the new ciphers within a few months. New applications default to the new configuration starting January 18, 2027.

CBC-mode ciphers have a long history of practical attacks (POODLE, BEAST, and Lucky Thirteen) and have been deprecated by browsers, operating systems, and the broader security community. Modern connections use AEAD cipher suites such as AES-GCM and ChaCha20-Poly1305, which avoid the entire class of padding-related attacks.

Affected cipher suites

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

After a subdomain rotates, clients that can only negotiate one of these ciphers will fail the TLS handshake with it. Any reasonably modern client (current browsers, mobile operating systems, and server runtimes) already prefers AEAD ciphers and is unaffected.

If you need continued CBC support, contact .

Jul 15

Choose what SAML sends as a login hint

Category: SAML
Published: Jul 15

Configure each SAML connection to send an email address, a custom attribute, or no login hint to your identity provider.

You can now control the identifier Clerk sends to your identity provider (IdP) when a member starts a SAML sign-in. Configure the Login hint section on each SAML connection in the Clerk Dashboard:

Email address sends the member's email address. This is the default for named SAML providers.
Custom attribute sends the value of a custom attribute that you select on the connection. Use this when your IdP identifies members with an employee ID, username, or another value instead of their email address.
Off sends no login hint.

Custom SAML connections don't send a login hint until you select Email address or Custom attribute. Existing named SAML connections keep their email-address behavior unless you change the setting.

For setup steps and details about custom attributes, see the SAML login hint documentation.