Clerk Changelog

JWTs are now the default for newly created applications, while existing applications continue using opaque tokens unless changed.

Why JWT?

JWT access tokens offer several advantages:

• Networkless verification — JWTs can be verified locally using your instance's public key, without making a network request to Clerk's servers
• Self-contained — All necessary information (user ID, scopes, expiration) is embedded in the token itself
• Better compatibility — Many third-party tools and libraries expect JWT tokens

When to use opaque tokens

Opaque tokens remain valuable for security-sensitive scenarios:

• Instant revocation — Opaque tokens can be invalidated immediately, while JWTs remain valid until they expire

How to configure

To change your OAuth access token format:

1. Navigate to OAuth applications⁠ in the Clerk Dashboard
2. Select the Settings tab
3. Toggle Generate access tokens as JWTs on or off
4. Save your changes

Clerk's SDKs automatically handle verification for both token formats — no code changes are required when switching between them. For manual verification of JWT tokens outside of Clerk's SDKs, use the same approach as session token verification with your instance's public key.

For more details on the differences between token formats, see the token formats documentation.

By default, your most recent time period (today, this week, or this month, depending on your selected interval) is shown even if the data is incomplete. Uncheck "Show incomplete period" to show only past complete periods. This filtering applies to all analytics reports on the Overview page.

As an initial action, we’re introducing the ability to set passwords as compromised, with the option to immediately sign out all active sessions for the affected user. This triggers a reset password session task, requiring the user to set a new password on their next sign-in. Additional actions will be introduced in the future.

How to force password resets for an entire instance

If you need to protect all users at once—such as during a suspected platform-wide security incident—you can require a password reset for every account in your instance.

This is currently done by setting all existing passwords as compromised, which will trigger a reset password session task for affected users. Each user will be required to set a new password the next time they sign-in.

1. Navigate to Configure > Instance Settings > Security Measures in your Clerk Dashboard.
2. Select Set all passwords as compromised.

How to force a password reset for a specific user

When only a single account is at risk, you can require a password reset for that user alone.

This action triggers a reset password session task for the user, ensuring they must change their password before continuing.

1. Navigate to the User Details page for the user.
2. In the Password section, under the actions dropdown, select Set password as compromised.

Getting started

All new instances have password reset session task enabled by default. Existing instances must manually opt-in via the Reset password session task update⁠ on the Updates page.

If you’re using custom authentication flows, make sure your application handles:

• The Reset password session task
• The associated password compromised error

You can now filter organizations in the Clerk Dashboard by name, slug, or creation date. These filters work alongside the existing search functionality to help you locate specific organizations faster.

Whether you need to find organizations by their display name, unique slug identifier, or when they were created, the new filter menu provides quick access to refine your organization list.

To use the filters, click the filter icon next to the search bar on the Organizations page⁠ in your application instance.

We're excited to announce new organization reports in the Clerk Dashboard. You can now monitor how many organizations are being created by day, week, and month. You can also track your total organization count at a glance.

These new reports provide quick insights into organization creation patterns, making it easier to monitor growth and identify trends in your organization adoption.

API keys are now available for authorization, with management built-in to the prebuilt components. This feature is part of the machine authentication suite.

Zero-Code UI Components

When you enable API keys in the Clerk Dashboard⁠, an API Keys tab appears in your <UserProfile /> and <OrganizationProfile /> components. Users can then create, view, and revoke their API keys.

You can also use the standalone <APIKeys /> component anywhere in your application:

import { APIKeys } from '@clerk/nextjs'

export default function Page() {
  return <APIKeys />
}

Backend SDK Integration

You can also create and manage API keys programmatically using the Backend SDK, with control over scopes, claims, and expiration:

const apiKey = await clerkClient.apiKeys.create({
  name: 'Production API Key',
  subject: 'user_xxx', // or 'org_xxx' for organization keys
  scopes: ['read:data', 'write:data'],
  secondsUntilExpiration: 86400, // optional: expires in 24 hours
})

// Store apiKey.secret immediately - it's only shown once!

Verify API Keys in Your Routes

Use the auth() helper to verify API keys in your backend. An example of this using Next.js is shown below:

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

export async function GET() {
  const { isAuthenticated, userId, scopes } = await auth({
    acceptsToken: 'api_key',
  })

  if (!isAuthenticated) {
    return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })
  }

  // Check scopes for fine-grained access control
  if (!scopes?.includes('read:data')) {
    return NextResponse.json({ error: 'Missing required scope' }, { status: 403 })
  }

  return NextResponse.json({ userId })
}

Key Features

• User & Organization scoped — Keys maintain identity context, always tied to a user or organization
• Instant revocation — API keys use opaque tokens (not JWTs), enabling immediate invalidation
• Scopes — Define exactly what each key can access
• Custom claims — Store additional metadata on keys (backend SDK only)
• Optional expiration — Set TTL or keep keys long-lived

Pricing

API keys are free to use during the beta period. After general availability, they'll move to a simple usage-based pricing model:

• $0.001 per key creation
• $0.00001 per key verification

Billing isn't live yet — we'll provide at least 30 days' notice before billing begins. We'll also provide usage stats and monitoring in the Dashboard before then, so you'll have complete visibility over your usage and costs.

Get Started Today

Ready to let your users create API keys? Check out these resources:

• API keys guide — Complete walkthrough of enabling and using API keys
• Backend SDK reference — Full API for creating, listing, verifying, and revoking keys
• Dashboard⁠ — Enable API keys for your application
• Tutorial — Build a SaaS application with Clerk and API keys, step by step

We'd love to hear your feedback as you try out API keys. Your input during the beta period will help us refine the feature. Have questions or suggestions? Reach out through our feedback portal⁠ or join the discussion in our Discord community.