---
name: Clerk Changelog
slug: clerk-changelog
type: feed
source_url: https://clerk.com/changelog
organization: Clerk
organization_slug: clerk
total_releases: 248
latest_date: 2026-10-06
last_updated: 2026-10-15
tracking_since: 2023-01-27
canonical: https://releases.sh/clerk/clerk-changelog
organization_url: https://releases.sh/clerk
---
Clerk shipped a major SDK refresh and broad push into platform integrations and billing features. Core 3 landed in March with improved customization APIs, a theme editor, and expanded keyless mode support across web and mobile; iOS and Android SDKs reached v1 with a unified auth surface, and @clerk/expo gained native React Native components plus native Google Sign-In. The platform expanded programmatic control—enterprise connections now support full CRUD via API, M2M tokens can issue as JWTs for networkless verification, and Chrome Extensions got vanilla JavaScript support. Billing features grew significantly with seat limits, custom plans and pricing, and role-based tiers through Organization Role Sets. Clerk integrated into Stripe Projects with CLI-based workflows, shipped native Convex support for Swift and Kotlin, and added AI tooling via MCP Server and installable Skills. The dashboard gained analytics exports, organization and user activity reports with retention tracking, and enterprise connection testing with shareable links. Security tightened with mandatory MFA enforcement across web and mobile, restrictions on identifier changes post-signup, and preview functionality for custom session claims.
March centered on platform expansion and developer capabilities. Core 3 shipped with improved customization APIs and modern React compatibility, while M2M tokens gained JWT format support for networkless verification. Enterprise features grew with programmatic enterprise connection management through the API, native React Native components landed in @clerk/expo with Google Sign-In, and Clerk became available in Stripe Projects for CLI-driven workflows.
## Multiple signing certificates for SAML connections
# Multiple signing certificates for SAML connections
Category
SSO
Published
Oct 6
SAML connections now support multiple certificates. Add your identity provider’s next signing certificate before it rotates keys, so SSO sign-ins keep working without downtime.
A SAML IdP signs every SSO response with a private key, and Clerk verifies it with the certificate stored on the enterprise connection. Until now, a connection held only one certificate, so a key rotation meant replacing it at exactly the moment the IdP switched: upload the new certificate too early, and sign-ins would fail while the IdP still used the old key; upload it too late, and they would fail once the IdP started using the new key.
A SAML enterprise connection now trusts up to five signing certificates at once. Add the IdP's next certificate ahead of time, let the IdP switch whenever it does, and remove the old certificate afterward. No sign-in is rejected on either side of the switch.
## How it works
Changing a connection's certificates replaces the entire list with the certificates you provide. If an update doesn't include certificates, the list stays the same. That's also how you stop trusting a leaked key: remove it from the list. Uploads take a single certificate or a PEM bundle, which many IdPs export when they list more than one signing key; every certificate in the bundle becomes an entry. Each certificate shows its expiry, with a warning when it expires within 30 days.
## Where to manage certificates
- **Clerk Dashboard**: the **Certificates** list on a SAML connection's **SSO** tab shows every trusted certificate with its expiry and lets you add one from a file (a PEM bundle adds several) or remove one.
- **Organization admins**: the **Security** tab of [``](/docs/reference/components/organization/organization-profile) and the [self-serve SSO](/docs/guides/configure/auth-strategies/enterprise-connections/self-serve-sso) setup show the same list for their Organization's connection, with the same upload and remove actions.
- **Backend API**: pass the full list as `idp_certificates` when you [create](/docs/reference/backend-api/tag/enterprise-connections/POST/enterprise_connections) or [update](/docs/reference/backend-api/tag/enterprise-connections/PATCH/enterprise_connections/%7Benterprise_connection_id%7D) an enterprise connection; responses include each certificate with its validity window. The single `idp_certificate` field keeps working, accepts a PEM bundle, and is deprecated.
## Get started
Multiple certificates are available on every instance with SAML enterprise connections; existing connections keep their current certificate as the only entry until you add more. Read the [certificate rotation guide](/docs/guides/configure/auth-strategies/enterprise-connections/certificate-rotation) for the step-by-step rotation and the API details.
Contributor
Maurício Antunes
## Self-serve Directory Sync
# Self-serve Directory Sync
Your customers' IT admins can set up Directory Sync for their own SSO connection, including Google Workspace, from the Security tab in ``.
[Directory Sync](/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync) provisions, updates, and deprovisions an Organization's members as its identity provider changes. Until now, your team configured it in the Clerk Dashboard and handed a SCIM endpoint and bearer token to each customer's IT admin. Self-serve Directory Sync moves that setup into the **Security** tab of [``](/docs/reference/components/organization/organization-profile), next to [self-serve SSO](/changelog/2026-06-26-self-serve-sso), so the admin who configured the SSO connection can finish provisioning without Dashboard access.
Note
Self-serve Directory Sync requires [Clerk Organizations](/docs/guides/organizations/overview) and builds on self-serve SSO. It's free in development instances. In production, your application needs the Pro or Business plan and the [B2B Authentication add-on](/pricing).
## How it works
When self-serve SSO is enabled for an Organization, a **Directory Sync** section appears beneath the SSO section in that Organization's Security tab. An admin with the `org:sys_entconns:manage` permission opens a three-step wizard. Clerk picks the directory provider from the SSO connection, so Okta Workforce, Microsoft Entra ID, Google Workspace, and custom SAML or OIDC connections each get the matching setup.
- **Configure**: For most identity providers, Clerk generates a SCIM endpoint URL and bearer token, along with setup instructions for that IdP. For Google Workspace, Clerk reads the directory through Google's Admin SDK. The admin uploads a service account key and enters the email address of a Workspace admin account for Clerk to act as.
- **Review attributes**: The standard mappings Clerk applies are listed, so the admin knows what will be stored.
- **Test provisioning**: The admin assigns a test user in their IdP and watches it appear. For Google Workspace, they can trigger a sync and see the result of the last run.
Provisioning works before the SSO connection is active, so an admin can populate the Organization's membership first and turn on SSO when they're ready. After setup, the admin can pause, resume, or remove the directory from the same section.
## What your team sees
In the Clerk Dashboard, a self-serve directory looks like any other directory. You still control [Custom attribute mapping](/docs/guides/configure/auth-strategies/enterprise-connections/custom-attribute-mapping) and [Role mapping](/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync#role-mapping), and Role mapping is off by default for self-serve directories..
## Get started
In the [Clerk Dashboard](https://dashboard.clerk.com/~/organizations), select an Organization, open its **Settings**, and turn on **Allow this organization to set up enterprise SSO and Directory Sync** under **Organization permissions**. The Security tab then surfaces wherever your app renders ``, including through ``.
For setup details and requirements, refer to the [self-serve Directory Sync documentation](/docs/guides/configure/auth-strategies/enterprise-connections/self-serve-directory-sync).
## SSO bypass
Sep 29
# SSO bypass
Category
SSO
Published
Sep 29
Let specific users sign in with an email code when their enterprise SSO connection is unavailable.
An active enterprise single sign-on (SSO) connection requires users on its domains to sign in through an identity provider (IdP). If the IdP goes down or the connection breaks because a certificate expires or a setting changes, those users can't sign in, including the people who need to fix the connection.
SSO bypass lets users on an allowlist sign in with a one-time email code instead of using the IdP. Everyone else must continue to use SSO.
## How it works
Add users to a connection's allowlist. When one of them enters their email address, [``](/docs/reference/components/authentication/sign-in) shows a **Can't use SSO?** link next to the SSO option. After confirming they want to continue without SSO, they get a code by email and sign in with an ordinary session. Users who aren't on the allowlist don't see the link.
You can only add users with a verified email address on a domain the connection serves. Clerk doesn't check whether the address still exists in your IdP. Clerk records each successful bypass as a `sign_in.sso_bypass.succeeded` event in [Application Logs](/docs/guides/dashboard/logs/application-logs).
## Who manages the allowlist
- **You** can manage the allowlist from the connection's page in the [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/sso-connections/enterprise) or with the [Backend API](/docs/reference/backend-api/tag/sso-bypass/POST/sso_bypass_allowlist_users). Both options work whether or not your application uses Organizations.
- **Organization members** with the `org:sys_entconns_sso_bypass:manage` [system permission](/docs/guides/organizations/control-access/roles-and-permissions#system-permissions) can manage their Organization's allowlist from the **Security** tab of [``](/docs/reference/components/organization/organization-profile). The default [**Admin**](/docs/guides/organizations/control-access/roles-and-permissions#default-roles) role includes this permission. They can add one member or all members with a given role.
## Get started
SSO bypass is available on every instance with enterprise connections. To use it, enable [**Email verification code**](/docs/guides/configure/auth-strategies/sign-up-sign-in-options#email) sign-in and add users to an allowlist. Read the [SSO bypass guide](/docs/guides/configure/auth-strategies/enterprise-connections/sso-bypass) to learn more, including how to support it in a custom sign-in flow.
Contributors
Maurício Antunes
Stephen Sibley
Steve Hayes
## Share this article
Copy linkCopied!
## Multiple enterprise connections per Organization
# Multiple enterprise connections per Organization
Link several SAML or OIDC connections to one Organization, and let more than one directory provision the same user.
An Organization can now have more than one enterprise connection. Previously, creating a second SAML or OIDC connection for an Organization that already had one failed with `organization_already_has_sso_connection`. That limit is gone across the [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/sso-connections) and the [Backend API](/docs/reference/backend-api/tag/saml-connections/POST/saml_connections).
## Why this matters
Some enterprise customers use more than one identity provider (IdP). This happens after an acquisition, during a migration from one IdP to another, or when subsidiaries and contractors sign in through separate providers. Before, each connection needed its own Organization. Now every connection can point to the same Organization, each with its own domain, protocol, and settings.
## Directory Sync follows
Because each enterprise connection can have its own [Directory Sync](/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync), a single Organization can now be fed by several directories, and the same person can be managed by more than one of them.
Clerk tracks each directory's view of a user separately:
- A user stays active while at least one enabled directory reports them as active. Clerk deactivates the user and revokes their sessions only when every enabled directory that manages them has deprovisioned them.
- Organization membership and Role mapping follow the directories that still grant access. Deprovisioning from one directory withdraws only that directory's grant. The membership is deleted only when no directory grants it anymore.
- Disabling or deleting a directory withdraws the memberships it granted without waiting for the IdP to sync. The recalculation runs in the background. Each affected user's status is recalculated from the remaining enabled directories: they are deactivated only if every one of those has deprovisioned them, and if none remain their status doesn't change.
## Get started
In the Clerk Dashboard, navigate to the [**SSO connections**](https://dashboard.clerk.com/~/user-authentication/sso-connections) page and add a connection for an Organization that already has one. Read the [Organization-level Enterprise SSO](/docs/guides/organizations/add-members/sso#multiple-enterprise-connections-per-organization) and [Directory Sync](/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync#users-managed-by-multiple-directories) docs to learn more.
## Client ID Metadata Documents are now generally available
CIMD is now available for every Clerk application. MCP and other public OAuth clients can connect with a URL-based identity, no support request required.
[Client ID Metadata Documents](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/) (CIMD) are now generally available for all Clerk applications.
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.
## What's changed since the beta
- **Available everywhere.** CIMD settings now appear on the [**OAuth applications**](https://dashboard.clerk.com/~/oauth-applications?oauth_applications_tab=settings) settings page for every application.
- **Off by default.** Nothing changes for your existing OAuth flows until you enable **Publish CIMD support**.
- **Same admission controls.** Explicitly allow clients by Client ID URL, choose their scopes, review implicitly allowed clients, and set **Client admission** to **Pre-registered clients only** to restrict flows to clients you've reviewed.
## Get started
1. In the Clerk Dashboard, navigate to the [**OAuth applications settings**](https://dashboard.clerk.com/~/oauth-applications?oauth_applications_tab=settings) page.
2. Under **Client onboarding**, enable **Publish CIMD support** to publish CIMD in your authorization server metadata.
3. Optionally, set **Client admission** to **Pre-registered clients only** and add the clients you trust from the **Applications** tab.
Read [Manage OAuth clients with Client ID Metadata Documents](/docs/guides/configure/auth-strategies/oauth/client-id-metadata-documents) for the full guide, including metadata requirements, PKCE, and client admission policies.
## Trace SMS delivery in Application Logs
Follow the delivery lifecycle of every Clerk-delivered SMS
[**Application Logs**](https://dashboard.clerk.com/~/application-logs) now record delivery events for SMS messages sent by Clerk, including phone verification codes, OTPs, and password reset codes. When a user reports a missing code, these events show whether the message was accepted, delivered, rejected, or left unconfirmed.
## The delivery lifecycle
Each message can generate several event types, helping you distinguish between a send failure, a delivery rejection, and an unknown outcome:
- `sms.accepted` — the delivery provider accepted the message (not yet proof it reached the phone)
- `sms.delivered` — the carrier confirmed delivery to the handset
- `sms.failed` — the send stopped before handoff, or the provider rejected it
- `sms.undeliverable` — the carrier could not deliver it after accepting it
- `sms.unconfirmed` — the provider reported an unknown delivery outcome
Failure events carry a normalized `reason` — like `invalid_phone_number`, `destination_unreachable`, or `rate_limited` — so a failure tells you whether to fix the number, wait out a provider limit, or adjust your own configuration. The message body, verification code, and provider identity are never included.
## Filtering and search
The dedicated [SMS logs view](https://dashboard.clerk.com/~/sms-logs) lists these events, where you can filter by a single event type like `sms.failed` or by the destination phone number to pull up one recipient's history. Every event for a single message shares a trace, so you can follow its whole timeline end to end.
## Get started
SMS events are available on all plans as part of Application Logs. Retention varies by plan. See the [pricing page](/pricing) for details. Open the [**SMS logs view**](https://dashboard.clerk.com/~/sms-logs) to investigate SMS delivery, or [**Application Logs**](https://dashboard.clerk.com/~/application-logs) to view SMS events alongside other application events. Read the [documentation](/docs/guides/dashboard/logs/sms-delivery-events) to learn more.
### Going forward
SMS delivery events build on Clerk's ongoing observability work alongside [Admin Logs](/changelog/2026-08-25-admin-logs) and [Email Logs](/changelog/2026-06-01-email-logs-public-beta).
## OAuth Device Authorization Grant
Sep 8
# OAuth Device Authorization Grant
Category
Product
Published
Sep 8
Authorize CLIs, TVs, and other input-constrained devices with a secure, standards-based OAuth flow.
OAuth 2.0 Device Authorization Grant is currently available in beta. To try it, [contact support](https://clerk.com/contact/support) to enable it for your workspace.
The grant provides a standards-based flow for applications that cannot open a browser or easily accept text input. CLIs, TVs, game consoles, and other devices can ask a user to approve access from a browser-capable device without entering their credentials on the original device.
## What's new
- **Device authorization and token polling.** Clients request a device code, display a short user code and verification URL, then poll for tokens at the interval Clerk provides.
- **Public and confidential clients.** Public clients send only their Client ID, while confidential clients authenticate with their Client ID and Client Secret.
- **Hosted user verification.** Clerk's Account Portal displays the OAuth application, requested scopes, Organization selection when applicable, and equally visible approve and deny actions.
- **Automatic discovery.** Clerk advertises `device_authorization_endpoint` and `urn:ietf:params:oauth:grant-type:device_code` through OAuth 2.0 and OpenID Connect metadata when Device Authorization Grant is available and the verification page is reachable.
Device Authorization Grant follows [RFC 8628](https://www.rfc-editor.org/rfc/rfc8628) and supports the same Clerk OAuth scopes, tokens, consent context, and Organization claims as the Authorization Code Flow. It does not use Proof Key for Code Exchange (PKCE) or redirect URIs.
See [Use OAuth Device Authorization Grant](/docs/guides/configure/auth-strategies/oauth/device-authorization-grant) to configure an OAuth application, implement device and token requests, and handle polling responses.
Contributor
Jeremy Wright
## Customize the reverification window
# Customize the reverification window
Category
Product
Published
Aug 28
Control how recently users must have authenticated before performing sensitive actions.
You can now customize how long a successful sign-in or reverification remains valid for Clerk-protected sensitive actions. Set the reverification window between 1 and 10 minutes. The default remains 10 minutes.
A shorter window can prompt users to verify their credentials more often before actions such as changing a password, adding and removing an email address, revoking a session, or deleting an account.
To configure the window, open the [**Sessions**](https://dashboard.clerk.com/~/sessions) page in the Clerk Dashboard. Under **Session lifetime**, set **Reverification window** to the number of minutes you want, between 1 and 10.
This setting applies to [sensitive actions protected by Clerk](/docs/guides/secure/reverification#sensitive-actions-that-require-reverification). For sensitive actions unique to your application, define the required window in your application. See the [reverification guide](/docs/guides/secure/reverification) for details.
## Audit Dashboard activity with Admin Logs
# Audit Dashboard activity with Admin Logs
An audit trail of admin actions across your workspace
The Clerk Dashboard now has [**Admin Logs**](https://dashboard.clerk.com/~/admin-logs): an audit trail of the configuration changes made across your workspace — from the Dashboard, the Backend API, or the Platform API. Admin Logs track actions like creating OAuth applications, updating instance settings, rotating secrets, and managing Roles and Permissions, [and more](/docs/guides/dashboard/logs/admin-logs).
## Filtering and search
The logs page shows a reverse-chronological feed of events. Each entry lists a description of what happened (e.g., "Brandon Romano created a user"), the application it happened in (when applicable), the originating IP address with a country flag (when available), and the timestamp. Select any entry to see its full details.
You can narrow the feed with filters:
- **Event type** — Filter by event type (e.g., `oauth_application.updated`, `domain.created`). Supports trailing wildcards (e.g., `oauth_application.*`).
- **Instance** — Filter by the instance the action targeted.
- **Application** — Filter by the application the action targeted.
- **Actor** — Filter by the actor that triggered the event.
- **IP address** — Filter by the IP address the action originated from.
- **Time range** — Scope results to a specific time window.
## Get started
Admin Logs are available on the Business and Enterprise plans — see the [pricing page](/pricing) for details. They start recording on August 24, 2026; actions before that date aren't included. Open [**Admin Logs**](https://dashboard.clerk.com/~/admin-logs) in the Clerk Dashboard, or read the [docs](/docs/guides/dashboard/logs/admin-logs).
### Going forward
Admin Logs join [Application Logs](/changelog/2026-05-06-application-logs) and [Email Logs](/changelog/2026-06-01-email-logs-public-beta) in Clerk's ongoing observability work.
## Custom OAuth scopes
# Custom OAuth scopes
Give MCP clients precise, discoverable access to your API with custom OAuth scopes.
Clerk now gives you finer control over the access that MCP clients can request from your API. Define custom OAuth scopes in the Clerk Dashboard to match the actions and resources your API supports.
For example:
- `messages:read`
- `tools:execute`
- `resources/files:read`
- `mcp_all`
Assign only the scopes that each OAuth application needs. Separately, choose which scopes to advertise through Clerk's OAuth metadata so MCP clients can discover what your application supports.
Open the **Scopes** tab on the [**OAuth applications**](https://dashboard.clerk.com/~/oauth-applications) page to get started.
To enforce scopes in your API, verify each OAuth access token and check its granted scopes. See [Verify OAuth tokens with Clerk](/docs/guides/configure/auth-strategies/oauth/verify-oauth-tokens).
## Biometric sign-in for Expo, iOS, and Android
Aug 17
# Biometric sign-in for Expo, iOS, and Android
Category
SDK
Published
Aug 17
Let returning mobile users sign in with a trusted device and the platform biometric prompt.
Clerk's mobile SDKs can now enroll a signed-in user's current device as a trusted device, then let returning users sign in with Face ID, Touch ID, or Android biometrics. Clerk verifies a device-bound challenge while the private key stays on the device.
Prebuilt auth and user profile views can show the enrollment prompt, biometric sign-in button, and current-device toggle. Custom flows can use the trusted-device APIs directly.
## Expo
Enroll
Sign in
Revoke
```
import { useTrustedDevices } from '@clerk/expo'
const { enroll } = useTrustedDevices()
await enroll()
```
```
import { useTrustedDevices } from '@clerk/expo'
const { signIn } = useTrustedDevices()
await signIn()
```
```
import { useTrustedDevices } from '@clerk/expo'
const { revoke } = useTrustedDevices()
await revoke(trustedDeviceId)
```
## iOS
Enroll
Sign in
Revoke
```
try await Clerk.shared.trustedDevices.enroll()
```
```
try await Clerk.shared.auth.signInWithTrustedDevice()
```
```
try await Clerk.shared.trustedDevices.revoke(id: trustedDeviceId)
```
## Android
Enroll
Sign in
Revoke
```
scope.launch {
Clerk.trustedDevices.enroll()
}
```
```
scope.launch {
Clerk.auth.signInWithTrustedDevice()
}
```
```
scope.launch {
Clerk.trustedDevices.revoke(trustedDeviceId)
}
```
See the biometric sign-in docs for setup and reference material:
- [iOS guide](/docs/ios/guides/development/custom-flows/authentication/biometric-sign-in)
- [Android guide](/docs/android/guides/development/custom-flows/authentication/biometric-sign-in)
- [Expo guide](/docs/expo/guides/development/custom-flows/authentication/biometric-sign-in)
Contributors
Sean Perez
Sam Wolfand
## Discounts and promo codes for Billing
# Discounts and promo codes for Billing
Apply percentage or fixed-amount discounts to a customer's subscription, or issue promo codes customers redeem at checkout.
Sometimes the list price isn't the right price. Sales closes a deal with a negotiated discount, you want to reward an early adopter, or you're running a launch promotion. Billing now supports discounts — apply them directly to a customer's subscription, or hand out a promo code customers redeem themselves at checkout.
## Create a discount once, use it anywhere
Discounts are reusable and flexible:
- **Percentage or fixed amount** — take 20% off, or $50 off
- **Any duration** — a single billing cycle, a set number of cycles, or indefinitely
- **Per-period amounts** — different discount amounts for monthly and annual plans
## Apply it yourself, or share a code
- **Manual discounts** — apply a discount to any subscriber's active subscription from the Dashboard. Revoke it at any time to return the subscription to its original price at the next renewal.
- **Promo codes** — publish a code (like `LAUNCH20`) that customers enter at checkout to redeem the discount themselves. Optionally cap the total number of redemptions, restrict redemption to new subscribers, and track how many times each code has been used.
Discounts and promo codes are available now for everyone using Clerk Billing. See the [docs](/docs/guides/billing/discounts) to get started.
## Connect OAuth clients with Client ID Metadata Documents
# Connect OAuth clients with Client ID Metadata Documents
Give MCP and other public OAuth clients URL-based identities without Dynamic Client Registration.
Clerk's OAuth provider now supports [Client ID Metadata Documents](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/) (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**](https://dashboard.clerk.com/~/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](https://clerk.com/contact/support) to enable it for your workspace.
Read [Manage OAuth clients with Client ID Metadata Documents](/docs/guides/configure/auth-strategies/oauth/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](https://feedback.clerk.com) or join the discussion in our [Discord community](https://clerk.com/discord).
## Connect OAuth clients with Client ID Metadata Documents
# Connect OAuth clients with Client ID Metadata Documents
Category
Product
Published
Aug 6
Give MCP and other public OAuth clients URL-based identities without Dynamic Client Registration.
Clerk's OAuth provider now supports [Client ID Metadata Documents](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/) (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**](https://dashboard.clerk.com/~/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](https://clerk.com/contact/support) to enable it for your workspace.
Read [Manage OAuth clients with Client ID Metadata Documents](/docs/guides/configure/auth-strategies/oauth/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](https://feedback.clerk.com) or join the discussion in our [Discord community](https://clerk.com/discord).
Contributor
Mitch Vostrez
## Google Workspace Directory Sync
Aug 5
# Google Workspace Directory Sync
Category
SSO
Published
Aug 5
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](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync#view-directory-users), [groups, and group memberships](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync#role-mapping).
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](https://dashboard.clerk.com/~/user-authentication/sso-connections) 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](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync) for the full setup guide.
## Sign-in-or-up now works with strict enumeration protection
`` 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 [``](/docs/reference/components/authentication/sign-in) 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](/docs/guides/secure/user-enumeration-protection#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 [``](/docs/reference/components/authentication/sign-in) 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](/docs/guides/secure/restricting-access#sign-up-modes).**
**Password can't be the starting strategy.** Either disable **Password** or [set the instance's preferred sign-in strategy to OTP](/docs/reference/backend-api/tag/instance-settings/PATCH/instance). 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, `` 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 [**Attack protection**](https://dashboard.clerk.com/~/protect/attack-protection) page in the Clerk Dashboard. If your app already renders `` as a combined [sign-in-or-up page](/docs/guides/development/custom-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](/docs/guides/development/custom-flows/authentication/sign-in-or-up#sign-in-or-up-with-sign-up-if-missing).
The [Account Portal](/docs/guides/account-portal/overview) 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 `` in your own app.
Contributors
Daniel Moerner
Robert Soriano
## Share this article
Copy linkCopied!
## Self-serve SSO for OIDC
Jul 31
# Self-serve SSO for OIDC
Category
SSO
Published
Jul 31
Your customers' IT admins can configure their own OpenID Connect connections from the Security tab in ``.
Your customers can now set up their own OIDC connections. [Self-serve SSO](/changelog/2026-06-26-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](/docs/guides/organizations/overview).
## How it works
The **Security** tab in [``](/docs/reference/components/organization/organization-profile) 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](https://dashboard.clerk.com/~/organizations), 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 ``.
For setup details and requirements, refer to the [self-serve SSO documentation](/docs/guides/configure/auth-strategies/enterprise-connections/self-serve-sso).
Contributor
Nicolas Lopes
## Hosted authentication for Expo, iOS, and Android
Let users sign in and sign up through the browser with Account Portal, Clerk’s hosted authentication pages
[Read more](https://clerk.com/changelog/2026-07-28-mobile-hosted-auth)
## Composable UserProfile and OrganizationProfile components
Build your own profile pages from Clerk’s building blocks, now available as an experimental API.
[Read more](https://clerk.com/changelog/2026-07-27-composable-profile-components)
## Connect your AI tools to Clerk MCP with one command
`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.
[Read more](https://clerk.com/changelog/2026-07-22-clerk-mcp)