Skip to main content

Clerk Changelog

@clerk/nextjs v6

Category
SDK
Published

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:

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.

Contributors
Bryce Kalow
Jacek Radko
Dylan Staley
Nikos Douvlis
Pantelis Eleftheriadis

Fastify SDK 2.0

Category
SDK
Published

Introducing Clerk's Fastify SDK 2.0 with support for Fastify v5

Fastify, the fast and low overhead web framework for Node.js, has recently shipped Fastify v5. In order to support Fastify v5 a new major version of @clerk/fastify had to be released. With Clerk's Fastify SDK 2.0 comes full support for Fastify v5 and no breaking changes for the Clerk SDK itself.

If you're using Fastify and @clerk/fastify, you can update like so:

  1. Follow the official Fastify v5 migration guide
  2. Install the latest version of @clerk/fastify
    npm install @clerk/fastify@latest
  3. You're done! No further changes needed

@clerk/fastify@^2.0.0 only supports Fastify v5 or later, if you want/need to continue using Fastify v4, please stick with @clerk/fastify@^1.0.0.

Contributor
Lennart Jörgens

Express SDK

Category
SDK
Published

Add authentication and authorization to your Express application in minutes with the new Clerk SDK

We're excited to announce the release of @clerk/express, our latest SDK designed specifically for Express applications.

The SDK comes fully equipped with server utilities and low level utilities for any of your custom flows.

Here's an example on how simple it is to protect a route with our Express SDK:

import express from 'express'
import { requireAuth } from '@clerk/express'

const app = express()

// if the user is not signed in, they will be redirected to /sign-in automatically
app.get('/protected', requireAuth({ signInUrl: '/sign-in' }), (req, res) => {
  return res.json({ userId: req.auth.userId })
})

Deprecating @clerk/clerk-sdk-node

With this release, we are initiating the process to deprecate @clerk/clerk-sdk-node.

During this transition period, we intend to:

  • Continue to provide critical patches and bug fixes for @clerk/clerk-sdk-node
  • Pause adding new features to @clerk/clerk-sdk-node
  • Focus our development efforts on @clerk/express

The transition to end @clerk/clerk-sdk-node support ends on January 8, 2025. To ensure a smooth transition, we've prepared a comprehensive Migration Guide with step-by-step instructions.

Upgrade today and experience enhanced authentication and user management in your Express projects with Clerk!

Contributor
Robert Soriano

Python Backend SDK

Category
SDK
Published

We've released a new backend SDK for Python! Here's a quick overview of its capabilities and some resources to help you get started.

We're pleased to announce the release of our server-side Python SDK!

With this launch, Python developers can more easily interface with the Clerk Backend API to manage users, organizations, and sessions.

Asynchronous backend API call with asyncio
import asyncio
from clerk_backend_api import Clerk

async def main():
    sdk = Clerk(
        bearer_auth="<YOUR_BEARER_TOKEN_HERE>",
    )
    res = await sdk.email_addresses.get_async(
        email_address_id="email_address_id_example"
    )
    if res is not None:
        # handle response
        pass

asyncio.run(main())

This release also makes it straightforward to authenticate backend requests in Django, Flask, and other Python web frameworks:

authenticateRequest in action
import os
import httpx
from clerk_backend_api import Clerk
from clerk_backend_api.jwks_helpers import AuthenticateRequestOptions

def is_signed_in(request: httpx.Request):
    sdk = Clerk(bearer_auth=os.getenv('CLERK_SECRET_KEY'))
    request_state = sdk.authenticate_request(
        request,
        AuthenticateRequestOptions(
            authorized_parties=['https://example.com']
        )
    )
    return request_state.is_signed_in

You can pip install the new clerk-backend-api module in any Python 3.8+ application to get started. To help you from there, we've prepared detailed reference documentation in the SDK GitHub repository.

Special thanks to Speakeasy for partnering with us on this SDK release 🎉!

Contributor
Jeff Escalante

Consolidating SSO Connections in the Dashboard

Category
Dashboard
Published

A more intuitive way to add SSO Connections.

We've made an update to the Clerk Dashboard that consolidates "Social Connections" and "Enterprise Connections" into one unified view.

We found through working with our customer's that this distinction was unclear and having to manage these in different places felt unintuitive. Going forward you can simply select the Add connection and choose whether you're attempting to set up a connection for all of your users, or only for users of a specific domain.

Consolidated SSO Connections
Contributor
Laura Beatris

Improve your Web3 application development experience using Clerk and Coinbase

We're excited to announce that Clerk has teamed up with Coinbase to make building Web3 applications easier. As a first step, Clerk released a new API today that allows developers to quickly integrate a customer's Coinbase Wallet with their Clerk user account. In addition, Clerk's embeddable <SignUp/> and <SignIn/> components now support authentication with Coinbase Wallet. Read our documentation to get started.

<SignIn/> with Coinbase Wallet and <UserProfile/> with Coinbase connection:

<SignIn/> with Coinbase Wallet and <UserProfile/> with Coinbase connection

Coinbase Wallet is a user-friendly, self-custodial solution that simplifies onchain transactions. Secured by Passkeys, it allows applications to cover gas fees, enabling users to pay with their Coinbase balance. This streamlined approach makes blockchain interactions more accessible, eliminating complex setups and lowering entry barriers to use products onchain.

Developers building with Clerk can now seamlessly connect user management with Coinbase Wallet functionality. This offers a path to building Web3 applications that prioritize speed of development, security, and ease of use.

We envision a future where identity-based enablement allows for more autonomous, efficient, and secure payment systems. By leveraging Clerk's user management capabilities, developers building on Coinbase Developer Platform are provided with a powerful suite of tools that goes beyond wallet integration – including robust session management, authorization controls, and tools for better customer engagement and retention.

We're eager to see how developers use these tools to more easily create new possibilities in Web3, and we're thrilled to deepen our collaboration with Coinbase Developer Platform to simplify onchain application development.

Contributors
Haris Chaniotakis
Emmanouela Pothitou