Sync users and groups directly from Google Workspace, with support for role mapping and custom attributes.
Directory Sync now supports Google Workspace. Clerk connects directly to your Workspace directory and syncs users, groups, and group memberships.
Clerk pulls the directory with a Google service account and computes changes, keeping your user base current without waiting for sign-in events.
Set up
Open a Google SAML connection in the Clerk Dashboard and select the Directory sync tab.
Upload a service account key with domain-wide delegation, along with the Workspace admin it should impersonate. Clerk validates the credentials against your directory before enabling Directory Sync.
If you disable it later, Clerk keeps the stored credentials so you can re-enable it with one click.
Works with role mapping and custom attributes
Google groups sync automatically and can be mapped to Clerk Roles.
Custom attribute mapping supports the full pulled directory record, including standard fields such as organizations.title and Workspace custom schemas such as customSchemas.EmployeeInfo.costCenter.
Map array paths to a multi-valued attribute to sync all items.
<SignIn /> now supports the combined sign-in-or-up flow under strict user enumeration protection. Visitors verify their identity first, then Clerk signs them in or creates the account. No code changes required.
At Clerk, we strive to provide an auth solution with the best user experience and the strongest security and privacy protections.
Many customers use our all-in-one <SignIn /> component to implement sign-in-or-up, a single entry point for their application: A visitor types their email address and Clerk decides whether to sign them in or create an account, so nobody has to remember whether they signed up before.
Previously, Strict user enumeration protection was incompatible with this flow. Strict enumeration protection hides whether an email address or phone number is already registered with your app, by never showing a "no account found" response when signing in.
Until now you had to pick one. We are happy to share that <SignIn /> now supports both together out-of-the-box, with no code changes needed.
Verify first, decide second
Under strict protection, a sign-in for an identifier that doesn't exist already continues to the verification screen instead of failing. Only after a visitor has proven their identity do we choose whether to sign them in or sign them up:
The visitor enters their email address or phone number.
Clerk shows the verification screen and sends a code or email link, whether or not the account exists.
The visitor enters the code or follows the link.
If the account exists, they're signed in. If it doesn't, Clerk creates it and continues to sign-up.
The order is what makes this safe. The visitor proves they control the address before Clerk commits to anything, so someone probing your sign-in page with addresses they don't own learns nothing either way. New and returning users see the same screens in the same number of steps.
A visitor without an account lands on a password screen they can never get past, and Clerk isn't allowed to explain why.
A visitor who enters the wrong password can't be offered "sign up instead?", because that would answer the question strict protection is hiding.
On development instances, <SignIn /> logs a sign_up_if_missing_password_preferred console warning when it detects this combination.
Username identifiers aren't supported either, since a username alone gives Clerk no way to contact the person to verify them.
Get started
Enable strict protection on the Rules page under Protect in the Clerk Dashboard. If your app already renders <SignIn /> as a combined sign-in-or-up page and is in Open access mode, it keeps working once you switch — there's no new prop and nothing to migrate.
If you're building your own interface, or you want this behavior without turning strict protection on, the signUpIfMissing option does the same thing in a custom flow. Refer to the sign-in-or-up custom flow guide.
The Account Portal hosts sign-in and sign-up on separate pages, so a sign-in-or-up experience there isn't available under any setting today. General support is on our roadmap. For now, render <SignIn /> in your own app.
Your customers' IT admins can configure their own OpenID Connect connections from the Security tab in <OrganizationProfile />.
Your customers can now set up their own OIDC connections. Self-serve SSO lets you delegate enterprise SSO configuration to your customers' IT admins, without giving them Dashboard access. In addition to SAML, it now supports custom OpenID Connect (OIDC) providers.
Note
Self-serve SSO is only available for applications using Clerk Organizations.
How it works
The Security tab in <OrganizationProfile /> now has an OpenID Connect (OIDC) group in the provider picker, alongside SAML. An admin with the org:sys_entconns:manage permission selects OIDC Provider and sets up the connection end-to-end:
Domains: Add one or more domains and verify ownership of each with a DNS TXT record.
Connection: Create an OIDC application in the identity provider using the authorized redirect URI Clerk displays, then supply the provider's endpoints — a discovery endpoint, or the authorization, token, and user info URLs — along with the client ID and client secret. Clerk reads sub and email from the ID token, and given_name and family_name when the provider sends them.
Test: Run a test sign-in to confirm the connection works end-to-end.
Activate: Turn the connection on once the test passes.
The connection is scoped to the Organization it's configured in and behaves like any other enterprise connection once it's live: users with a matching email domain sign in through the configured provider.
Get started
Self-serve SSO is enabled per Organization. In the Clerk Dashboard, select an Organization, open its Settings, and turn on Allow this organization to set up enterprise SSO under Organization permissions. The Security tab then surfaces wherever your app renders <OrganizationProfile />.
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.
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.
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
npminstall@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:
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.
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:
clerkmcpinstall
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 themclerkmcpinstall--clientclaude--clientcursorclerkmcpinstall--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:
