We've released version 2.0 of the Chrome Extension SDK. Learn about the SDK's new features and get started building your Chrome Extension today.
We're excited to release version 2.0 of the Chrome Extension SDK. Version 2.0 comes with the new createClerkClient() helper for background service workers, improved support for syncing auth state with your web application and detailed documentation for the SDK.
Introducing createClerkClient() for Service Workers
Chrome Extensions pose a unique challenge for developers using Clerk. When the popup or side panel is closed, the Clerk session cookie will become stale. The createClerkClient() function is specifically designed to allow extension developers to refresh the user's session, obtain a valid token or other auth, and retrieve user data.
You can now send a message from a content script to the background service worker and get auth status or a token for the user.
This easiest way for enterprises to adopt full-featured SSO.
EASIE Enterprise Connections
We've added a new Enterprise Connection type: EASIE SSO. EASIE is a new way for applications to provide enterprise-grade SSO through a multi-tenant OpenID provider, created by Clerk.
No more SSO Fees
Along with the launch of EASIE support, we’re eliminating usage-based SSO connection fees entirely (previously $50/mo each) to make enterprise SSO more accessible than ever, including SAML SSO connections. Your current billing cycle will be the last one with these per-connection fees.
Read the full blog post to learn more about EASIE and why we're cutting our SSO prices so drastically.
Customize your Sign Up with a Terms of Service and Privacy Policy checkbox.
Keep your application compliant by requiring legal consent on your application's <SignUp /> views.
If you are using Clerk’s pre-built component or the Account Portal, simply enable it from the Clerk Dashboard. Your users will be required to accept your legal documents before they are allowed to create an account, and you will have one less compliance issue to worry about.
Export your users whenever you need to. They're yours, after all.
Previously, your user exports weren't as accessible as we would have liked. Customers had to export via our Backend API or if you needed hashed passwords, you had to rely on our support team to trigger a user export.
Now you can easily generate and download a CSV export of your users, all within the Clerk Dashboard.
Key Features:
Settings Page: This new feature is added to the dashboard Settings.
Export and Download Logs: The Settings page also includes a table displaying logs for both export requests and downloads, providing a complete history of export activities.
Real-time export management: Trigger user exports with the new "Export All Users" button. Track progress in real-time with status updates displayed on the Exports logs table on the Settings page, including when the file is ready for download.
Automatic notifications: Once the export completes, you’ll receive a toast notification and can download the CSV file directly from the dashboard.
Flexible navigation: You can navigate away or switch tabs without interrupting the export process, and you’ll still get notified when the export is done.
Other Details:
The download button remains visible until the file expires, allowing you to download the list at any time before requesting a new one.
The export is restricted to admins (or users in their personal workspace), ensuring the feature is secure and accessible only to authorized users.
Introducing @clerk/nextjs v6, with support for Next.js 15.
The Next.js team has announced the stable release of Next.js 15, and Clerk is continuing the tradition of (nearly) same-day support for new major Next.js releases with the release of @clerk/nextjs v6.
Get started by running the Clerk upgrade CLI:
Not ready to upgrade to Next.js v15? No problem: @clerk/nextjs v6 is backwards compatible with Next.js v14, including the switch to static rendering by default.
Asynchronous auth() (breaking change)
Now that Next.js's request APIs are asynchronous, Clerk's auth() helper will follow suit. In addition to supporting Next.js's new async APIs, this change will also allow the addition of more robust validations and new functionality into the auth() helper. Stay tuned!
With the change to async, we weren't happy with how the usage of auth().protect() felt, so we moved protect to be a property of auth, instead of part of the return value.
To make migration as easy as possible, we're also including a codemod that will update your usages of auth() and auth().protect(). For situations where the codemod isn't able to update your code, please see the upgrade guide for detailed steps.
Static rendering by default, opt-in dynamic (and partial prerendering support)
Historically, usage of <ClerkProvider> has opted your entire application in to dynamic rendering due to the dynamic and personalized nature of auth-related data. We've heard the feedback from our users that this default didn't feel like it aligned with Next.js best practices. Starting with v6, <ClerkProvider> will no longer opt your entire application into dynamic rendering by default. This change also brings support for Next.js's upcoming Partial Prerendering mode (PPR). PPR allows a page to be both static and dynamic by moving the optimization from pages to components.
Dynamic auth data is still available by using the auth() helper in a server component. This data can also be passed to client components directly as needed. This is the recommended way to access auth data going forward. For existing applications that use the useAuth() hook in Client Components that are server-side rendered, this is a breaking change. Wrap these components in <ClerkProvider dynamic> to make auth data available to the hook during rendering. As a best practice, we recommend wrapping usage of <ClerkProvider dynamic> with suspense to ensure your page is setup to take advantage of PPR.
If you want <ClerkProvider> to continue making dynamic auth data available by default, add the dynamic prop to your root <ClerkProvider>:
This opts every single page into dynamic rendering, or PPR when enabled. For this reason, it is still recommended to take a more granular approach to dynamic data access by using <ClerkProvider dynamic> further down your component tree.
To learn more about Next.js's different rendering modes and how Clerk interacts with them, check out the documentation.
Removal of deprecated APIs
A number of deprecated APIs have been removed as part of this release: