Clerk Changelog

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.

Take a look at our Chrome Extension Quickstart if you're just getting started, or read over the Chrome Extension documentation to learn about all of the features.

Our Chrome Extension Quickstart repo⁠ and Chrome Extension Demo repo⁠ are a great reference or starting point for a project.

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.

import { createClerkClient } from '@clerk/chrome-extension/background'

const publishableKey = process.env.PLASMO_PUBLIC_CLERK_PUBLISHABLE_KEY

// create a new Clerk instance and get a fresh token for the user
async function getToken() {
  const clerk = await createClerkClient({
    publishableKey,
  })

  // if there is no user session, then return nothing
  if (!clerk.session) {
    return null
  }

  // return the user's token
  return await clerk.session?.getToken()
}

// create a listener to listen for messages from content scripts
chrome.runtime.onMessage.addListener((request, sender, sendResponse) => {
  console.log('Handling request for the users current token')

  getToken()
    .then((token) => {
      sendResponse({ token })
    })
    .catch((error) => {
      console.error('[Service Worker]: Error occured -> ', JSON.stringify(error))
      sendResponse({ token: null })
    })

  return true // REQUIRED: Indicates that the listener responds asynchronously.
})

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.

// send a message to the background service worker
chrome.runtime.sendMessage({ greeting: 'get-token' }, (response) => {
  // you can now have access to the user's token
  console.log(response.token)
})

Breaking Changes

• syncSessionWithTab has been removed and replaced with syncHost. Changelog⁠ Sync Host Guide⁠
• The storage host permission is now required. Changelog⁠

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.

Launching a new product but not ready to open it up to everyone yet? Waitlist Sign-up mode is here to help you manage early access seamlessly.

What's New?

With Waitlist Sign-up mode, you have complete control over onboarding new users:

• Your <Waitlist /> component collects prospective users’ email addresses.
• These users are added to a Waitlist queue in your Clerk Dashboard⁠.
• You decide which entries get accepted or rejected. Or simply invite new users directly.
• Once your product is ready for the world, just switch your Sign-up mode to public and you're live 🚀.

Give it a try

• Visit your Clerk Dashboard⁠.
• Learn more about the Waitlist Sign-Up Mode.

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.

Ready to dive in?

Head to your Clerk Dashboard⁠, or check out the documentation to get started.

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.

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:

npx @clerk/upgrade

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!

import { auth } from '@clerk/nextjs/server'

export default async function Page() {
  const { userId } = await auth()

  if (!userId) {
    return <h1>Hello, guest!</h1>
  }

  return <h1>Hello, {userId}!</h1>
}

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.

import { auth } from '@clerk/nextjs/server'

export default async function Page() {
  const { userId } = await auth.protect()

  return <h1>Hello, {userId}!</h1>
}

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.

import { Suspense } from 'react'
import { ClerkProvider } from '@clerk/nextjs'

export default function Page() {
  return (
    <main>
      <header>
        <Logo />
        <Suspense fallback={<FallbackAvatar />}>
          <ClerkProvider dynamic>
            <UserAvatar />
          </ClerkProvider>
        </Suspense>
      </header>
    </main>
  )
}

If you want <ClerkProvider> to continue making dynamic auth data available by default, add the dynamic prop to your root <ClerkProvider>:

import { ClerkProvider } from '@clerk/nextjs'

export default function RootLayout({ children }) {
  return (
    <ClerkProvider dynamic>
      <html>
        <body>{children}</body>
      </html>
    </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:

• authMiddleware() - use clerkMiddleware() instead
• redirectToSignIn() - use const { redirectToSignIn } = await auth() instead
• redirectToSignUp() - use const { redirectToSignUp } = await auth() instead
• clerkClient singleton - use await clerkClient() instead

For more information, please see the upgrade guide.