Clerk Changelog

We're excited to announce the launch of our new Solana⁠ authentication strategy, which makes it easy for developers to integrate Solana wallet sign-ins into their applications.

Getting Started

• Enable Solana as a Web3 authentication strategy in the Clerk Dashboard⁠
• Use the <SignIn/> and <SignUp/> components to allow users to authenticate with their Solana wallets
• See our Solana authentication documentation for detailed setup instructions and code examples

You can now control which roles are available to each organization using Role Sets. Assign different Role Sets to different organizations based on subscription tiers, customer cohorts, or business needs — if a role isn't in an organization's Role Set, members can't be assigned that role.

What's new

Role Sets allow you to define separate collections of roles and permissions across organizations. This enables advanced use cases like:

• Creating different role hierarchies for different teams or departments
• Isolating permissions across multiple products or services within one organization
• Building flexible multi-tenant architectures with customizable access patterns
• Supporting complex organizational structures with varying authorization needs

Use Role Sets when different Organizations need different available Roles. This works well for:

• Different pricing tiers - Your Free plan offers only admin and member, Pro adds moderator and analyst, and Enterprise adds security_admin and compliance_officer.
• Different customer cohorts - Small practices get physician and nurse, while large hospitals also get department_head and specialist. All cohorts share admin and member, but get additional Roles specific to their size.

When you modify a Role Set, the changes are automatically applied to all Organizations using it. This makes it easy to roll out new Roles across multiple Organizations at once.

Each instance gets one role set by default at no additional cost. Additional role sets require the Enhanced Organizations add-on.

Getting started

Visit the Role Sets documentation⁠ to learn how to create and manage Role Sets for your organizations.

You can also manage Role Sets through the Clerk Dashboard or programmatically via the Backend API. Visit the Role Sets documentation⁠ for detailed guides, or see the Backend API reference⁠ for API details.

In an ongoing effort to improve the security of your Clerk instances, starting today, only users of your Clerk workspace who are Admin roles will be able to manage secret keys on the Instance / API Keys page. The Member role can no longer reveal, create, or delete secret keys.

Member role can still list all Secret keys and view non-sensitive details such as name, creation date and last-used date.

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