Enforce the usage of your IdP even when customer's initiate using SSO
From now on when a user attempts to authenticate using OAuth/SSO with an email address domain that is already managed by an Enterprise connection, the user is redirected to their IdP in order to complete the flow
More control to operate your B2B SaaS via Custom Roles and Permissions
Previously within our Organizations product you had 2 role types to work with (Admin and Member) out-of-the-box. Those roles came with a bunch of default assumptions about how they operated and what rights they each had. For many of our customers, this worked fine – but for a large amount of our more mature customers, you required more. That's where Custom Roles and Permissions comes into play.
With Custom Roles and Permisisons you can now model your application with whatever roles map to your use-case, assign those roles the specific permissions they need and you're on your way. This data gets automatically reflected in your session tokens as claims, ready for you to build out authorization flows within your app.
We didn't just stop at allowing you to model your application's roles and permissions and enrich your Sessions and JWTs. In pursuit of the best possible DX, like with our <SignUp /> and <SignIn /> components, we took it a step further.
Introducing has(), protect(), and <Protect> - our new authorization helpers. These helpers allow the convenient integration of your custom authorization needs directly inside your apps.
<Protect role="org:admin">
<Link href="/admin">Admin Panel</Link>
</Protect>Head to the verifying a user's permissions docs to see all 3 helpers in action.
As of today, custom roles and permissions is in public beta. Simply head to the Dashboard and start configuring your application's roles today.
If you're looking for more detail about the release, read through our announcement blog post, or dive right into the Roles and Permission docs.
We're excited to see what you build 🚀.
Get a better understanding of your user's activity by using our updated Backend API endpoints which are now filterable by activity
Use the new last_active_at_since parameter to filter users according
to their latest activity date.
For example, if you were interested to know which users were active between 2023-11-23 and the current day, you could construct a query like this:
GET /v1/users?last_active_at_since=1700690400000Note that session activity is registered continuously throughout the day so a query using a condition with the current day is perfectly valid.
You can also use last_active_at as an ordering parameter to sort users by how recently they were active:
GET /v1/users?order_by=last_active_atYou will also now get last_active_at in your response when retrieving
user details with the GET /users/{user_id} endpoint.
Introducing a better pricing structure for all companies, and a better way to see your usage.
We've completely overhauled and simplified our pricing structure. All plans now include 10k MAUs! Our announcement blog post explains the rationale behind this major shift. For a complete break down, check out our beautifully redesigned pricing page.
We've also overhauled the Plan & Billing section of our Dashboard so you can more easily understand your current plans usage. If you're one of the folks who shared that our old billing section was inadequate, this update is for you.
You may notice a new look and feel that it's disjointed with the rest of our site. We're working hard behind the scenes on a complete overhaul of our dashboard! Stay tuned for an improved experience...
Fight back against bots and protect your users from brute-force attacks with Account Lockout
Account Lockout is a feature that protects you and your users from brute-force attacks where bots or other nefarious actors repeatedly attempt to gain access. In addition to our other methods of bot detection, now, when a configurable limit of attempts is exceeded – the user's account will be temporarily locked, and they will be prompted to wait for a cooldown period before they can try again.
This prevents malevolent actors from guessing users' credentials by trying out multiple possible codes in rapid succession (brute-force attack).
Well, nothing. We've enabled Account Lockout on all accounts with default settings that shouldn't be intrusive for your users but will certainly inconvenience bots and scripts.
Starting today, you can head to our User & Authentication > Attack Protection and configure the settings to your application's needs. Specifically, you're able to adjust the number of failed attempts before a user's account is locked and the duration for which they will be prevented from signing in afterwards.
It is also possible to disable Account Lockout, but we highly recommend you keep it on :)
Head to our docs to learn more about brute force attacks and locking user accounts.
Hono is a great minimal web framework for building applications across any edge runtime and now with Hono's middleware and our community SDK, you can secure it with Clerk.
To install the Clerk middleware for Hono, follow the instructions provided to set up and configure the middleware in Hono.
npm i hono @hono/clerk-auth @clerk/backendBefore you start using the Clerk middleware, you'll need to set the following environment variables:
CLERK_SECRET_KEY=<your-secret-key>
CLERK_PUBLISHABLE_KEY=<your-publishable-key>Here is a quick example on how to use the Clerk middleware for Hono:
import { clerkMiddleware, getAuth } from '@hono/clerk-auth'
import { Hono } from 'hono'
const app = new Hono()
app.use('*', clerkMiddleware())
app.get('/', (c) => {
const auth = getAuth(c)
if (!auth?.userId) {
return c.json({
message: 'You are not logged in.',
})
}
return c.json({
message: 'You are logged in!',
userId: auth.userId,
})
})
export default appAnd that's it. Your app is now secured and running on the edge. Find more about Clerk's Hono middleware on GitHub.