On the shoulders of giants, as they say...

Early in Stripe's lifetime, they launched a new style of resource ID's to a great deal of fanfare. The ID's are prefixed with an abbreviation of the object they represented. For example:

Patrick Collison offered the motivation for these prefixes on 

At Clerk, we're big fans of the prefix and knew early on that we wanted to offer their convenience to our own customers.

That was the easy part of generating our IDs— we spent a lot more time deciding what to put 

For the uninitiated, ID generation is a surprisingly wide subject area with many important considerations.

For a long time, it was commonplace for developers to rely on sequential IDs generated by the database. There are artifacts of this practice all over the web - but these days, they tend to be avoided because:

They can easily be guessed. This isn't inherently a problem, but many, many security vulnerabilities are made worse when attackers can guess resource IDs. On a more light-hearted note, a "bug" involving guessable IDs 

They can reveal a lot of information about application usage. Again, this isn't inherently a problem, but it can lead to unintended side effects. One example came recently when StackOverflow sold to Prosus, and there was 

discussion on HackerNews about the low user IDs

 some users had, indicating they were an early user.

They're impossible to generate in distributed systems. For modern applications, this should be the primary concern. If a system has servers in two different regions, it's impossible for them to generate sequential IDs independently, without coordination - but coordination would likely undermine the point of distributing the system in the first place.

To mitigate these issues, randomness has been introduced into ID generation. Enough randomness ensures that IDs cannot be guessed and that collisions are avoided in distributed systems.

 - also eliminate a trait of sequential IDs that developers love: they're sortable.

Finding a middle ground between sortable and unique IDs was a primary motivation behind two newer ID generators:

To generate the roughly-sorted 64 bit ids in an uncoordinated manner, we settled on a composition of: timestamp, worker number and sequence number.

It borrows core ideas from the ubiquitous UUID standard, adding time-based ordering and more friendly representation formats.

After considering both Snowflake and KSUID, we decided to use KSUID for our primary ID generator. The key factor in our decision was that Twitter's Snowflake included a worker number, which we did not need.

Combined with Stripe-like prefixes, our IDs look like this:

Generating sortable Stripe-like IDs with Segment's KSUIDs

 components. But since launching our B2B SaaS Suite for onboarding business customers, our top feature request has become better 

 capabilities: not just helping developers determine 

 a user is, but also what permissions they have within their organization.

Today we’ve launched two new features to make robust authorization easy:

In Clerk’s dashboard, developers can now define custom roles, which their business customers can assign to their employees. Previously, roles were restricted to just “admin” and “member.”

In addition, fine-grained permissions can now be defined and mapped to roles. When used properly, this extra layer of abstraction allows developers to create additional roles as-needed, without making any changes to their codebase.

Each role and permission defined in Clerk’s dashboard has a corresponding key, like 

To make it easy to leverage permissions for authorization checks, we’ve introduced three new helpers in our SDKs.

 function on both the frontend and the backend to determine if the active user “has” a particular role or permission.

 can be used anywhere that Clerk returns an “auth” object:

 in client components, including during SSR

 in server contexts outside of the App Router (Remix Loaders, Node, Express, Fastify, etc)

, which takes definitive action to block further processing, instead of allowing developers to manually handle the unauthorized case. It is intended to be used in cases where unauthorized users are assumed to be attackers.

Consider an endpoint that your product would never issue a request to unless the current user is authorized. For example, you may have a page with a button that can issue requests to that endpoint, but the page is only accessible to authorized users. That is the perfect place to use 

 – you don't need a precisely-written error, just confidence that an attacker's requests will fail.

 has launched in Next.js only, though we will extend the helper to other frameworks in the future. Please use 

 to request the feature for your framework.

 component is intended to block further processing. It only renders children for authorized users, and optionally renders a 

 can be used across all React frameworks, in CSR, SSR, and RSC contexts.

For full details and usage information, please see our updated Organization documentation, including:

Authorization is now a core feature of Clerk

With today’s launch, authorization has become a core feature of Clerk, and you will see significant, continued investment in the future.

In 2024, we will extend our authorization helpers to support entitlements, so Clerk can be used to gate features based on the subscription plan a customer selected.

Further, you likely noticed above that every role and permission is namespaced with the 

 prefix, which relates to the Organization resource. We recognize this is limiting, and in the future we will be extending our authorization helpers to work with other resources.

Introducing has(), protect(), and <Protect>

Clerk’s components were created with you in mind. Components do most of the functional work for you, allowing you to get your auth flows working in minutes, and support customization to fit your app’s style. That said, sometimes a component like the 

 doesn’t suit the needs of your application. The good news? Clerk provides hooks and functions that make building your custom UI components easy. Let’s take a quick look at how to create your custom user menu.

The hardest part of building a custom user menu is often the dropdown menu itself. You need the button to trigger the menu opening, a way to close it, a way to track open/closed states, a way to handle ‘click off’ to close, logic to close if the user hits the 

 button, a way to handle keyboard input, and the list goes on. We’re going to save ourselves some time and use a great library while doing so. Radix provides world-class, accessible, unstyled 

 that you can use to quickly and efficiently build your UI. Let’s start by installing the primitive we need — the dropdown menu.

Once the installation finishes, let’s create the scaffolding for our new component. The following will be the foundation of the menu. The trigger will hold the User button that will open the menu, and each item will hold one of the menu entries. Remember that Radix Primitives are unstyled and there is no content so this will be blank.

The first content we will add is the User button. This will show that the user is logged in, and will be the trigger to open the menu. For the sake of this post we will assume that you have marked email as required in the Clerk Dashboard, in the 

User & Authentication → Email, Password, Username → Email

 section to ensure every user has an email. You could change this to a first name or username easily enough. Just make sure that whatever option you choose is something that will exist for all users, for the sake of rendering. You could also conditionally render different information depending on what the user has provided — show the first name if available; if not, show the email.

To build the button we will leverage the 

 hook. This gives us access to information about the user, such as profile image, email, name, and more. We will also make sure that Clerk and the user have loaded, and that there is valid user data, before rendering the User button.

Add the Sign-Out and Manage Account Buttons

With the User button in place, we can now add Sign Out and Manage Account buttons. The 

 hook provides the two methods we will need for this — the 

 method. The User Profile will open as a modal. You could, instead, mount the 

 component to its own route, and then link it to the route. For the Sign Out button, we will also need to use the Next.js router to handle the redirect.

The custom button has now replicated the behavior of the 

, though it is very much still unstyled. We’re going to do one more thing — add one more menu entry to mimic expanding the menu. This will use the 

 component from Next.js to link to a fictional 

Your new component is almost ready — it just needs some styling. Let’s add a little bit to get started. The code below is ready to drop right into your app, and then you can import the new 

Explore the Powerful Customization Options Clerk Offers!

 documentation to explore more ways to customize your application using the many hooks and methods Clerks provides.

For more in-depth technical inquiries or to engage with our community, feel free to 

. Stay in the loop with the latest Clerk features, enhancements, and sneak peeks by following our Twitter/X account, 

. Your journey to seamless user management starts here!

Need help?

Engineering

Engineering

Generating sortable Stripe-like IDs with Segment's KSUIDs

Twitter's Snowflake

Segment's KSUID

Clerk's ID generator

Start now,
no strings attached

Pricing built for
businesses of all sizes.

Newsletter!

Engineering

Engineering

Generating sortable Stripe-like IDs with Segment's KSUIDs

Segment's KSUID

Clerk's ID generator

Start now,no strings attached

Pricing built for.css-qa8l2m{color:var(--chakra-colors-primary-500);}businesses of all sizes.

Newsletter!

Start now,
no strings attached

Pricing built for
businesses of all sizes.