Clerk Changelog

Clerk's OAuth provider now supports Client ID Metadata Documents⁠ (CIMD), available today as a beta.

A compatible client uses an HTTPS URL as its client_id. Clerk fetches the metadata document at that URL and validates the client's identity and redirect URIs. This gives MCP and other public OAuth clients a stable identity without a pre-issued client ID, client secret, or Dynamic Client Registration.

Control which clients can connect

The new CIMD Clients tab on the OAuth applications⁠ page lets you:

• Explicitly allow a client by its Client ID URL and choose its scopes.
• Allow supported popular clients with suggested scopes.
• Review each client's admission status and metadata fetch health.
• Edit scopes, refresh metadata, or delete a saved client.
• Decide whether unknown clients may connect.
• Block clients that were implicitly allowed during an earlier connection.

Enable Advertise CIMD support to publish CIMD in your authorization server metadata. Once you do, any CIMD client can connect and Clerk records it when it first connects so you can review it later. Enable Only allow pre-registered clients to connect at the same time to restrict OAuth flows to clients you've reviewed in advance.

Get started

CIMD is currently available in beta. To try it, contact support⁠ to enable it for your workspace.

Read Manage OAuth clients with Client ID Metadata Documents to learn how CIMD works and how to configure client admission policies.

We'd love to hear your feedback as you try out CIMD. Your input during the beta period will help us refine the feature. Have questions or suggestions? Reach out through our feedback portal⁠ or join the discussion in our Discord community⁠.

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.

See the Directory Sync docs⁠ for the full setup guide.

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:

1. The visitor enters their email address or phone number.
2. Clerk shows the verification screen and sends a code or email link, whether or not the account exists.
3. The visitor enters the code or follows the link.
4. 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.

Requirements

Your instance must allow public sign-ups.

Password can't be the starting strategy. Either disable Password or set the instance's preferred sign-in strategy to OTP⁠. Under strict protection, a password step has no safe exit:

• 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 allows public sign-ups, 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 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.

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

For setup details and requirements, refer to the self-serve SSO documentation.

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

iOS

Android

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.

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:

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:

Compose your own sections

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

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.