{"id":"src_M4sZyGVjPaGt67qbjuo0z","slug":"clerk-changelog","name":"Clerk Changelog","type":"feed","url":"https://clerk.com/changelog","orgId":"org_6JdxTmhM4dqZsi_ghliSQ","productId":null,"productSlug":null,"org":{"id":"org_6JdxTmhM4dqZsi_ghliSQ","slug":"clerk","name":"Clerk"},"isPrimary":false,"isHidden":false,"discovery":"curated","metadata":"{\"feedUrl\":\"https://clerk.com/changelog/atom.xml\",\"feedType\":\"unknown\",\"feedDiscoveredAt\":\"2026-04-07T23:42:17.213Z\",\"noFeedFound\":false,\"feedEtag\":\"W/\\\"924bb90b24bdc3c9dffba4047bce8f7c\\\"\",\"feedContentLength\":\"191060\",\"feedContentDepth\":\"summary-only\",\"enrichment\":{\"consecutiveFailures\":0},\"sourceActor\":{\"nextAlarmAt\":\"2026-10-15T18:30:01.391Z\",\"lastAlarmAt\":\"2026-10-15T14:30:03.267Z\",\"managed\":true}}","notice":null,"kind":"platform","stars":null,"starsFetchedAt":null,"releaseCount":248,"releasesLast30Days":6,"avgReleasesPerWeek":1.6,"latestVersion":null,"latestDate":"2026-10-06T00:00:00.000Z","changelogUrl":null,"hasChangelogFile":false,"lastFetchedAt":"2026-10-15T14:33:39.323Z","lastPolledAt":"2026-10-15T14:33:27.898Z","changeDetectedAt":null,"trackingSince":"2023-01-27T20:23:00.000Z","releases":[{"id":"rel_DDoUuKpMHD4-4LLHz7Egx","version":null,"type":"feature","title":"Multiple signing certificates for SAML connections","summary":"Enterprise SAML connections now trust up to five signing certificates at once, letting you add an IdP's next certificate before a key rotation so sign-ins keep working across the switch. Certificates are managed as a full list via idp_certificates on the Backend API or the Certificates list in the Dashboard, and the single idp_certificate field still works but is deprecated.","titleGenerated":"Clerk SAML connections now trust multiple signing certificates","titleShort":"SAML connections trust up to 5 signing certificates","breaking":"minor","importance":3,"content":"# Multiple signing certificates for SAML connections\n\nCategory\n\nSSO\n\nPublished\n\nOct 6\n\nSAML 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.\n\nA 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.\n\nA 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.\n\n## How it works\n\nChanging 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.\n\n## Where to manage certificates\n\n- **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.\n- **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.\n- **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.\n\n## Get started\n\nMultiple 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.\n\n\n\nContributor\n\nMaurício Antunes","publishedAt":"2026-10-06T00:00:00.000Z","fetchedAt":"2026-10-06T23:39:13.726Z","url":"https://clerk.com/changelog/2026-10-02-multiple-saml-signing-certificates","media":[],"coverageCount":0},{"id":"rel_0aTLwrBruaJl5Eyh3XwEf","version":null,"type":"feature","title":"Self-serve Directory Sync","summary":"IT admins can now set up Directory Sync for their own SSO connection from the Security tab in , including Google Workspace via Google Admin SDK, instead of relying on a SCIM endpoint and bearer token handed over by the customer's team. Enrollment requires Organizations plus the Pro or Business plan with B2B Authentication add-on in production, and the feature is off until enabled under Organization permissions in the Dashboard.","titleGenerated":"Clerk launches self-serve Directory Sync for Organization admins","titleShort":"Directory Sync now self-serve in OrganizationProfile","breaking":"none","importance":4,"content":"# Self-serve Directory Sync\n\nYour customers' IT admins can set up Directory Sync for their own SSO connection, including Google Workspace, from the Security tab in ``.\n\n\n\n[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.\n\nNote\n\nSelf-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).\n\n## How it works\n\nWhen 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.\n\n- **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.\n- **Review attributes**: The standard mappings Clerk applies are listed, so the admin knows what will be stored.\n- **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.\n\nProvisioning 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.\n\n## What your team sees\n\nIn 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..\n\n## Get started\n\nIn 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 ``.\n\nFor setup details and requirements, refer to the [self-serve Directory Sync documentation](/docs/guides/configure/auth-strategies/enterprise-connections/self-serve-directory-sync).","publishedAt":"2026-09-30T00:00:00.000Z","fetchedAt":"2026-09-30T21:36:09.901Z","url":"https://clerk.com/changelog/2026-09-30-self-serve-directory-sync","media":[],"coverageCount":0},{"id":"rel_x7nhTOb29mumKa7CA1rG0","version":null,"type":"feature","title":"SSO bypass","summary":"SSO bypass lets users on a connection's allowlist sign in with a one-time email code when the enterprise IdP is unavailable, via a Can't use SSO? link in the SignIn component, while everyone else must continue using SSO. The allowlist is managed from the Clerk Dashboard or the Backend API, or by Organization members with the org:sys_entconns_sso_bypass:manage system permission, and each successful bypass is recorded as a sign_in.sso_bypass.succeeded event in Application Logs.","titleGenerated":"Clerk adds SSO bypass so allowlisted users can sign in by email code","titleShort":"SSO bypass: allowlisted users sign in via email code","breaking":"none","importance":3,"content":"Sep 29\n\n# SSO bypass\n\nCategory\n\nSSO\n\nPublished\n\nSep 29\n\nLet specific users sign in with an email code when their enterprise SSO connection is unavailable.\n\nAn 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.\n\nSSO 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.\n\n## How it works\n\nAdd 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.\n\nYou 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).\n\n## Who manages the allowlist\n\n- **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.\n- **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.\n\n## Get started\n\nSSO 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.\n\n\n\nContributors\n\nMaurício Antunes\n\nStephen Sibley\n\nSteve Hayes\n\n## Share this article\n\nCopy linkCopied!","publishedAt":"2026-09-29T00:00:00.000Z","fetchedAt":"2026-09-29T21:15:35.570Z","url":"https://clerk.com/changelog/2026-09-29-sso-bypass","media":[],"coverageCount":0},{"id":"rel_UCMjqIChLOICR6e91nLYm","version":null,"type":"feature","title":"Multiple enterprise connections per Organization","summary":"An Organization can now have more than one SAML or OIDC enterprise connection, removing the organization_already_has_sso_connection error, and each connection can have its own directory. Clerk tracks each directory's view of a user separately: a user stays active while at least one enabled directory reports them active, and memberships are only deleted when no directory grants them anymore.","titleGenerated":"Clerk allows multiple enterprise connections per Organization","titleShort":"Multiple SSO connections per Organization; multi-directory provisioning","breaking":"none","importance":3,"content":"# Multiple enterprise connections per Organization\n\nLink several SAML or OIDC connections to one Organization, and let more than one directory provision the same user.\n\nAn 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).\n\n## Why this matters\n\nSome 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.\n\n## Directory Sync follows\n\nBecause 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.\n\nClerk tracks each directory's view of a user separately:\n\n- 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.\n- 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.\n- 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.\n\n## Get started\n\nIn 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.","publishedAt":"2026-09-24T00:00:00.000Z","fetchedAt":"2026-09-24T19:32:45.705Z","url":"https://clerk.com/changelog/2026-09-24-multiple-enterprise-connections-per-organization","media":[],"coverageCount":0},{"id":"rel_fR0RNuuR6bgLY7VYcIomF","version":null,"type":"feature","title":"Client ID Metadata Documents are now generally available","summary":"Client ID Metadata Documents are generally available for every Clerk application, letting MCP and other public OAuth clients use an HTTPS URL as their client_id that Clerk fetches and validates for identity and redirect URIs, without a pre-issued client ID, client secret, or Dynamic Client Registration. The feature is off by default and must be enabled via Publish CIMD support in the OAuth applications settings, with existing client admission controls including a pre-registered-clients-only mode.","titleGenerated":"Clerk makes Client ID Metadata Documents generally available for all apps","titleShort":"CIMD now GA for all Clerk apps; off by default","breaking":"none","importance":3,"content":"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.\n\n[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.\n\nA 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.\n\n## What's changed since the beta\n\n- **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.\n- **Off by default.** Nothing changes for your existing OAuth flows until you enable **Publish CIMD support**.\n- **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.\n\n## Get started\n\n1. In the Clerk Dashboard, navigate to the [**OAuth applications settings**](https://dashboard.clerk.com/~/oauth-applications?oauth_applications_tab=settings) page.\n2. Under **Client onboarding**, enable **Publish CIMD support** to publish CIMD in your authorization server metadata.\n3. Optionally, set **Client admission** to **Pre-registered clients only** and add the clients you trust from the **Applications** tab.\n\nRead [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.","publishedAt":"2026-09-21T00:00:00.000Z","fetchedAt":"2026-09-21T22:34:33.757Z","url":"https://clerk.com/changelog/2026-09-17-client-id-metadata-documents-ga","media":[],"coverageCount":0},{"id":"rel_fpL70Qp-xAdiZJFuPfwNl","version":null,"type":"feature","title":"Trace SMS delivery in Application Logs","summary":"Application Logs now record delivery events for Clerk-sent SMS including phone verification codes, OTPs, and password reset codes, with event types sms.accepted, sms.delivered, sms.failed, sms.undeliverable, and sms.unconfirmed. A dedicated SMS logs view filters by event type or destination phone number, with failure events carrying a normalized reason such as invalid_phone_number or rate_limited; message bodies, verification codes, and provider identity are excluded.","titleGenerated":"Clerk adds SMS delivery tracing to Application Logs","titleShort":"SMS delivery lifecycle now traced in Application Logs","breaking":"none","importance":3,"content":"Follow the delivery lifecycle of every Clerk-delivered SMS\n\n[**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.\n\n## The delivery lifecycle\n\nEach message can generate several event types, helping you distinguish between a send failure, a delivery rejection, and an unknown outcome:\n\n- `sms.accepted` — the delivery provider accepted the message (not yet proof it reached the phone)\n- `sms.delivered` — the carrier confirmed delivery to the handset\n- `sms.failed` — the send stopped before handoff, or the provider rejected it\n- `sms.undeliverable` — the carrier could not deliver it after accepting it\n- `sms.unconfirmed` — the provider reported an unknown delivery outcome\n\nFailure 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.\n\n## Filtering and search\n\nThe 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.\n\n## Get started\n\nSMS 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.\n\n### Going forward\n\nSMS 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).","publishedAt":"2026-09-17T00:00:00.000Z","fetchedAt":"2026-09-18T21:33:08.428Z","url":"https://clerk.com/changelog/2026-09-17-sms-logs","media":[],"coverageCount":0},{"id":"rel_YaJ788vFomZ4O-dAlhdLF","version":null,"type":"feature","title":"OAuth Device Authorization Grant","summary":"Clerk now supports the OAuth 2.0 device authorization grant, letting CLI tools, TVs, and other input-constrained applications complete device authorization flows. The grant is available today and follows the standard RFC 8628 flow.","titleGenerated":"Clerk adds OAuth device authorization grant flow","titleShort":"OAuth device authorization grant flow added","breaking":"none","importance":3,"content":"Sep 8\n\n# OAuth Device Authorization Grant\n\nCategory\n\nProduct\n\nPublished\n\nSep 8\n\nAuthorize CLIs, TVs, and other input-constrained devices with a secure, standards-based OAuth flow.\n\n\n\nOAuth 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.\n\nThe 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.\n\n## What's new\n\n- **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.\n- **Public and confidential clients.** Public clients send only their Client ID, while confidential clients authenticate with their Client ID and Client Secret.\n- **Hosted user verification.** Clerk's Account Portal displays the OAuth application, requested scopes, Organization selection when applicable, and equally visible approve and deny actions.\n- **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.\n\nDevice 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.\n\nSee [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.\n\n\n\nContributor\n\nJeremy Wright","publishedAt":"2026-09-08T00:00:00.000Z","fetchedAt":"2026-09-08T22:11:28.946Z","url":"https://clerk.com/changelog/2026-09-08-device-authorization-grant","media":[],"coverageCount":0},{"id":"rel_GKI2aaXRr0clkE7oXc9Om","version":null,"type":"feature","title":"Customize the reverification window","summary":"Clerk now lets you control how long a successful sign-in or reverification stays valid for sensitive actions, setting the window between 1 and 10 minutes via the Sessions page in the Dashboard. The default remains 10 minutes; a shorter window prompts more frequent credential verification before actions like password changes, email edits, session revocation, or account deletion.","titleGenerated":"Clerk lets you customize the reverification window for sensitive actions","titleShort":"Reverification window customizable (1–10 min)","breaking":"none","importance":3,"content":"# Customize the reverification window\n\nCategory\n\nProduct\n\nPublished\n\nAug 28\n\nControl how recently users must have authenticated before performing sensitive actions.\n\n\n\nYou 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.\n\nA 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.\n\nTo 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.\n\nThis 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.","publishedAt":"2026-08-28T00:00:00.000Z","fetchedAt":"2026-08-28T22:28:15.803Z","url":"https://clerk.com/changelog/2026-08-28-customize-reverification-window","media":[],"coverageCount":0},{"id":"rel_zoUh-NJOKcfpaSmnaPIhS","version":null,"type":"feature","title":"Audit Dashboard activity with Admin Logs","summary":"Admin Logs in the Clerk Dashboard records configuration changes made via the Dashboard, Backend API, or Platform API, with filtering by event type, instance, application, actor, IP address, and time range. Available on Business and Enterprise plans, recording starts August 24, 2026; actions before that date aren't included.","titleGenerated":"Clerk adds Admin Logs audit trail for Dashboard, Backend, and Platform API actions","titleShort":"Admin Logs audit trail covers all admin actions","breaking":"none","importance":3,"content":"# Audit Dashboard activity with Admin Logs\n\nAn audit trail of admin actions across your workspace\n\n\n\nThe 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).\n\n## Filtering and search\n\nThe 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.\n\nYou can narrow the feed with filters:\n\n- **Event type** — Filter by event type (e.g., `oauth_application.updated`, `domain.created`). Supports trailing wildcards (e.g., `oauth_application.*`).\n- **Instance** — Filter by the instance the action targeted.\n- **Application** — Filter by the application the action targeted.\n- **Actor** — Filter by the actor that triggered the event.\n- **IP address** — Filter by the IP address the action originated from.\n- **Time range** — Scope results to a specific time window.\n\n## Get started\n\nAdmin 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).\n\n### Going forward\n\nAdmin 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.","publishedAt":"2026-08-25T00:00:00.000Z","fetchedAt":"2026-08-25T21:26:31.827Z","url":"https://clerk.com/changelog/2026-08-25-admin-logs","media":[],"coverageCount":0},{"id":"rel_AoMW_DnyAEVyw1odVV2PA","version":null,"type":"feature","title":"Custom OAuth scopes","summary":"Clerk now lets you define custom OAuth scopes (e.g. `messages:read`, `tools:execute`) in the Dashboard and assign them per OAuth application, with separate control over which scopes are advertised through OAuth metadata for MCP client discovery. Start from the Scopes tab on the OAuth applications page.","titleGenerated":"Clerk adds custom OAuth scopes for MCP client access control","titleShort":"Custom OAuth scopes for precise MCP API access","breaking":"none","importance":3,"content":"# Custom OAuth scopes\n\nGive MCP clients precise, discoverable access to your API with custom OAuth scopes.\n\nClerk 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.\n\nFor example:\n\n- `messages:read`\n- `tools:execute`\n- `resources/files:read`\n- `mcp_all`\n\nAssign 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.\n\nOpen the **Scopes** tab on the [**OAuth applications**](https://dashboard.clerk.com/~/oauth-applications) page to get started.\n\nTo 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).","publishedAt":"2026-08-21T00:00:00.000Z","fetchedAt":"2026-08-22T00:07:47.064Z","url":"https://clerk.com/changelog/2026-08-21-custom-oauth-scopes","media":[],"coverageCount":0},{"id":"rel_ygLIMW4B2-Fk0INMsqwx8","version":null,"type":"feature","title":"Biometric sign-in for Expo, iOS, and Android","summary":"Clerk's mobile SDKs let returning users sign in with Face ID, Touch ID, or Android biometrics by enrolling the current device as trusted; Clerk verifies a device-bound challenge while the private key stays on-device. Prebuilt auth and user profile views can show the enrollment prompt, biometric sign-in button, and current-device toggle, and custom flows can use the trusted-device APIs directly.","titleGenerated":"Clerk adds biometric sign-in for Expo, iOS, and Android","titleShort":"Biometric sign-in arrives for mobile SDKs","breaking":"none","importance":3,"content":"Aug 17\n\n# Biometric sign-in for Expo, iOS, and Android\n\nCategory\n\nSDK\n\nPublished\n\nAug 17\n\nLet returning mobile users sign in with a trusted device and the platform biometric prompt.\n\nClerk'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.\n\nPrebuilt 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.\n\n## Expo\n\nEnroll\n\nSign in\n\nRevoke\n\n```\nimport { useTrustedDevices } from '@clerk/expo'\n\nconst { enroll } = useTrustedDevices()\n\nawait enroll()\n```\n\n```\nimport { useTrustedDevices } from '@clerk/expo'\n\nconst { signIn } = useTrustedDevices()\n\nawait signIn()\n```\n\n```\nimport { useTrustedDevices } from '@clerk/expo'\n\nconst { revoke } = useTrustedDevices()\n\nawait revoke(trustedDeviceId)\n```\n\n## iOS\n\nEnroll\n\nSign in\n\nRevoke\n\n```\ntry await Clerk.shared.trustedDevices.enroll()\n```\n\n```\ntry await Clerk.shared.auth.signInWithTrustedDevice()\n```\n\n```\ntry await Clerk.shared.trustedDevices.revoke(id: trustedDeviceId)\n```\n\n## Android\n\nEnroll\n\nSign in\n\nRevoke\n\n```\nscope.launch {\n Clerk.trustedDevices.enroll()\n}\n```\n\n```\nscope.launch {\n Clerk.auth.signInWithTrustedDevice()\n}\n```\n\n```\nscope.launch {\n Clerk.trustedDevices.revoke(trustedDeviceId)\n}\n```\n\nSee the biometric sign-in docs for setup and reference material:\n\n- [iOS guide](/docs/ios/guides/development/custom-flows/authentication/biometric-sign-in)\n- [Android guide](/docs/android/guides/development/custom-flows/authentication/biometric-sign-in)\n- [Expo guide](/docs/expo/guides/development/custom-flows/authentication/biometric-sign-in)\n\n\n\nContributors\n\nSean Perez\n\nSam Wolfand","publishedAt":"2026-08-17T00:00:00.000Z","fetchedAt":"2026-08-18T19:04:10.304Z","url":"https://clerk.com/changelog/2026-08-17-biometric-sign-in-mobile-sdks","media":[],"coverageCount":0},{"id":"rel_Vm1TFknt0fzmV_Va9C3gD","version":null,"type":"feature","title":"Discounts and promo codes for Billing","summary":"Apply percentage or fixed-amount discounts to any subscription from the Dashboard, or issue promo codes customers redeem at checkout. Discounts support any duration or per-period amounts and can be capped or restricted to new subscribers.","titleGenerated":"Clerk Billing adds discounts and promo codes for subscriptions","titleShort":"Billing discounts and checkout promo codes land","breaking":"none","importance":3,"content":"# Discounts and promo codes for Billing\n\nApply percentage or fixed-amount discounts to a customer's subscription, or issue promo codes customers redeem at checkout.\n\nSometimes 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.\n\n\n\n## Create a discount once, use it anywhere\n\nDiscounts are reusable and flexible:\n\n- **Percentage or fixed amount** — take 20% off, or $50 off\n- **Any duration** — a single billing cycle, a set number of cycles, or indefinitely\n- **Per-period amounts** — different discount amounts for monthly and annual plans\n\n## Apply it yourself, or share a code\n\n- **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.\n- **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.\n\nDiscounts and promo codes are available now for everyone using Clerk Billing. See the [docs](/docs/guides/billing/discounts) to get started.","publishedAt":"2026-08-10T00:00:00.000Z","fetchedAt":"2026-08-11T00:26:11.859Z","url":"https://clerk.com/changelog/2026-08-10-discounts-and-promo-codes","media":[],"coverageCount":0},{"id":"rel_-1wDVkV6jJz1RV6oYcVM9","version":null,"type":"feature","title":"Connect OAuth clients with Client ID Metadata Documents","summary":"Clerk's OAuth provider now supports Client ID Metadata Documents (CIMD) in beta, letting MCP and other public OAuth clients use an HTTPS URL as their client_id. Admins control admission via a new CIMD Clients tab, with options to allow or block unknown clients.","titleGenerated":"Clerk adds beta Client ID Metadata Documents support for OAuth clients","titleShort":"CIMD gives OAuth clients URL-based identities","breaking":"none","importance":3,"content":"# Connect OAuth clients with Client ID Metadata Documents\n\nGive MCP and other public OAuth clients URL-based identities without Dynamic Client Registration.\n\nClerk'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.\n\nA 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.\n\n## Control which clients can connect\n\nThe new **CIMD Clients** tab on the [**OAuth applications**](https://dashboard.clerk.com/~/oauth-applications) page lets you:\n\n- Explicitly allow a client by its Client ID URL and choose its scopes.\n- Allow supported popular clients with suggested scopes.\n- Review each client's admission status and metadata fetch health.\n- Edit scopes, refresh metadata, or delete a saved client.\n- Decide whether unknown clients may connect.\n- Block clients that were implicitly allowed during an earlier connection.\n\nEnable **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.\n\n## Get started\n\nCIMD is currently available in beta. To try it, [contact support](https://clerk.com/contact/support) to enable it for your workspace.\n\nRead [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.\n\nWe'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).","publishedAt":"2026-08-06T00:00:00.000Z","fetchedAt":"2026-08-07T15:16:40.401Z","url":"https://clerk.com/changelog/2026-08-06-client-id-metadata-documents","media":[],"coverageCount":0},{"id":"rel_HnwxyCN1ByzmsKdME6Lpw","version":null,"type":"feature","title":"Connect OAuth clients with Client ID Metadata Documents","summary":"Clerk's OAuth provider now supports Client ID Metadata Documents (CIMD) in beta, letting MCP and other public OAuth clients use an HTTPS URL as their client_id instead of a pre-issued ID, client secret, or Dynamic Client Registration. A new CIMD Clients tab on the OAuth applications page controls which clients can connect, with options to pre-register clients, block unknown ones, and advertise CIMD support in the authorization server metadata.","titleGenerated":"Clerk OAuth adds Client ID Metadata Documents support in beta","titleShort":"CIMD gives public OAuth clients URL-based identities","breaking":"none","importance":3,"content":"# Connect OAuth clients with Client ID Metadata Documents\n\nCategory\n\nProduct\n\nPublished\n\nAug 6\n\nGive MCP and other public OAuth clients URL-based identities without Dynamic Client Registration.\n\nClerk'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.\n\nA 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.\n\n## Control which clients can connect\n\nThe new **CIMD Clients** tab on the [**OAuth applications**](https://dashboard.clerk.com/~/oauth-applications) page lets you:\n\n- Explicitly allow a client by its Client ID URL and choose its scopes.\n- Allow supported popular clients with suggested scopes.\n- Review each client's admission status and metadata fetch health.\n- Edit scopes, refresh metadata, or delete a saved client.\n- Decide whether unknown clients may connect.\n- Block clients that were implicitly allowed during an earlier connection.\n\nEnable **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.\n\n## Get started\n\nCIMD is currently available in beta. To try it, [contact support](https://clerk.com/contact/support) to enable it for your workspace.\n\nRead [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.\n\nWe'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).\n\n\n\nContributor\n\nMitch Vostrez","publishedAt":"2026-08-06T00:00:00.000Z","fetchedAt":"2026-08-07T03:06:36.300Z","url":"https://clerk.com/changelog/2026-08-05-client-id-metadata-documents","media":[],"coverageCount":0},{"id":"rel_2txVg1cZYMjNm-W39rnAz","version":null,"type":"feature","title":"Google Workspace Directory Sync","summary":"Clerk Directory Sync now supports Google Workspace, connecting directly to your directory to sync users, groups, and group memberships via a service account. Supports role mapping for groups and custom attribute mapping including standard fields and Workspace custom schemas.","titleGenerated":"Clerk adds Google Workspace Directory Sync","titleShort":"Google Workspace directory sync joins Clerk","breaking":"none","importance":3,"content":"Aug 5\n\n# Google Workspace Directory Sync\n\nCategory\n\nSSO\n\nPublished\n\nAug 5\n\nSync users and groups directly from Google Workspace, with support for role mapping and custom attributes.\n\nDirectory 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).\n\nClerk pulls the directory with a Google service account and computes changes, keeping your user base current without waiting for sign-in events.\n\n## Set up\n\nOpen a Google SAML connection in the [Clerk Dashboard](https://dashboard.clerk.com/~/user-authentication/sso-connections) and select the **Directory sync** tab.\n\nUpload 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.\n\nIf you disable it later, Clerk keeps the stored credentials so you can re-enable it with one click.\n\n## Works with role mapping and custom attributes\n\nGoogle groups sync automatically and can be mapped to Clerk Roles.\n\nCustom attribute mapping supports the full pulled directory record, including standard fields such as `organizations.title` and Workspace custom schemas such as `customSchemas.EmployeeInfo.costCenter`.\n\nMap array paths to a multi-valued attribute to sync all items.\n\nSee the [Directory Sync docs](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync) for the full setup guide.","publishedAt":"2026-08-05T00:00:00.000Z","fetchedAt":"2026-08-05T22:42:28.894Z","url":"https://clerk.com/changelog/2026-08-05-google-workspace-directory-sync","media":[],"coverageCount":0},{"id":"rel_m2ZrBp2hblMo0p2LSWk18","version":null,"type":"feature","title":"Sign-in-or-up now works with strict enumeration protection","summary":"SignIn component now supports the combined sign-in-or-up flow under strict user enumeration protection, with no code changes required. Visitors verify their identity before Clerk signs them in or creates the account.","titleGenerated":"Clerk combined sign-in-or-up now works with strict enumeration protection","titleShort":"Sign-in-or-up flow compatible with strict enumeration protection","breaking":"none","importance":4,"content":"`` 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.\n\nAt Clerk, we strive to provide an auth solution with the best user experience and the strongest security and privacy protections.\n\nMany 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.\n\nPreviously, [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.\n\nUntil 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.\n\n## Verify first, decide second\n\nUnder 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:\n\n1. The visitor enters their email address or phone number.\n2. Clerk shows the verification screen and sends a code or email link, whether or not the account exists.\n3. The visitor enters the code or follows the link.\n4. If the account exists, they're signed in. If it doesn't, Clerk creates it and continues to sign-up.\n\nThe 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.\n\n## Requirements\n\n**Your instance must allow [public sign-ups](/docs/guides/secure/restricting-access#sign-up-modes).**\n\n**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:\n\n- A visitor without an account lands on a password screen they can never get past, and Clerk isn't allowed to explain why.\n- A visitor who enters the wrong password can't be offered \"sign up instead?\", because that would answer the question strict protection is hiding.\n\nOn development instances, `` logs a `sign_up_if_missing_password_preferred` console warning when it detects this combination.\n\nUsername identifiers aren't supported either, since a username alone gives Clerk no way to contact the person to verify them.\n\n## Get started\n\nEnable 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.\n\nIf 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).\n\nThe [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.\n\n\n\nContributors\n\nDaniel Moerner\n\nRobert Soriano\n\n## Share this article\n\nCopy linkCopied!","publishedAt":"2026-08-04T00:00:00.000Z","fetchedAt":"2026-08-04T22:21:56.612Z","url":"https://clerk.com/changelog/2026-08-04-sign-in-or-up-strict-enumeration","media":[],"coverageCount":0},{"id":"rel_iv8Rq1Ytj57Bh9InrBqPp","version":null,"type":"feature","title":"Self-serve SSO for OIDC","summary":"Customers' IT admins can now configure custom OpenID Connect connections from the Security tab in <OrganizationProfile />, alongside the existing SAML support. Self-serve SSO is enabled per Organization from the Clerk Dashboard.","titleGenerated":"Clerk adds self-serve OIDC SSO configuration for Organization customers","titleShort":"Organization IT admins can self-configure OIDC SSO","breaking":"none","importance":4,"content":"Jul 31\n\n# Self-serve SSO for OIDC\n\nCategory\n\nSSO\n\nPublished\n\nJul 31\n\nYour customers' IT admins can configure their own OpenID Connect connections from the Security tab in ``.\n\nYour 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.\n\nNote\n\nSelf-serve SSO is only available for applications using [Clerk Organizations](/docs/guides/organizations/overview).\n\n## How it works\n\nThe **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:\n\n- **Domains**: Add one or more domains and verify ownership of each with a DNS `TXT` record.\n- **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.\n- **Test**: Run a test sign-in to confirm the connection works end-to-end.\n- **Activate**: Turn the connection on once the test passes.\n\nThe 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.\n\n## Get started\n\nSelf-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 ``.\n\nFor setup details and requirements, refer to the [self-serve SSO documentation](/docs/guides/configure/auth-strategies/enterprise-connections/self-serve-sso).\n\n\n\nContributor\n\nNicolas Lopes","publishedAt":"2026-07-31T00:00:00.000Z","fetchedAt":"2026-07-31T20:59:59.577Z","url":"https://clerk.com/changelog/2026-07-30-self-serve-sso-oidc","media":[],"coverageCount":3},{"id":"rel_Phx31w3nqnrktVKpqKDfN","version":null,"type":"feature","title":"Hosted authentication for Expo, iOS, and Android","summary":"Let users sign in and sign up through the browser with Account Portal, Clerk’s hosted authentication pages\n\n[Read more](https://clerk.com/changelog/20...","titleGenerated":null,"titleShort":null,"breaking":"unknown","importance":null,"content":"Let users sign in and sign up through the browser with Account Portal, Clerk’s hosted authentication pages\n\n[Read more](https://clerk.com/changelog/2026-07-28-mobile-hosted-auth)","publishedAt":"2026-07-28T00:00:00.000Z","fetchedAt":"2026-07-28T17:40:32.373Z","url":"https://clerk.com/changelog/2026-07-28-mobile-hosted-auth","media":[],"coverageCount":0},{"id":"rel_NW2wF-1maioVsPO9B9EcX","version":null,"type":"feature","title":"Composable UserProfile and OrganizationProfile components","summary":"UserProfile and OrganizationProfile are now available as composable building blocks under an experimental API.","titleGenerated":"Clerk adds composable UserProfile and OrganizationProfile components as experimental API","titleShort":"Profile pages now built from composable Clerk components","breaking":"none","importance":3,"content":"Build your own profile pages from Clerk’s building blocks, now available as an experimental API.\n\n[Read more](https://clerk.com/changelog/2026-07-27-composable-profile-components)","publishedAt":"2026-07-27T00:00:00.000Z","fetchedAt":"2026-07-27T19:37:32.748Z","url":"https://clerk.com/changelog/2026-07-27-composable-profile-components","media":[],"coverageCount":0},{"id":"rel_ayc9mIxKu0A3iByIn5zQU","version":null,"type":"feature","title":"Connect your AI tools to Clerk MCP with one command","summary":"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.","titleGenerated":"Clerk MCP server installs across AI clients with one command","titleShort":"Clerk MCP installs in ten AI clients with one command","breaking":"none","importance":3,"content":"`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.\n\n[Read more](https://clerk.com/changelog/2026-07-22-clerk-mcp)","publishedAt":"2026-07-22T00:00:00.000Z","fetchedAt":"2026-07-23T02:01:40.995Z","url":"https://clerk.com/changelog/2026-07-22-clerk-mcp","media":[],"coverageCount":0}],"pagination":{"nextCursor":"2026-07-22T00:00:00.000Z|2026-07-23T02:01:40.995Z|rel_ayc9mIxKu0A3iByIn5zQU","limit":20},"summaries":{"rolling":{"windowDays":90,"summary":"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.","releaseCount":29,"generatedAt":"2026-04-09T20:37:06.190Z"},"monthly":[{"year":2026,"month":3,"summary":"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.","releaseCount":9,"generatedAt":"2026-04-09T20:37:07.970Z"}]}}