man clerk
Plain-language answers to the questions this lab keeps poking at: what a Clerk session token is, what the JWT actually carries, and how to read it on the server. Independent notes, not official docs.
A Clerk session token is a short-lived JWT that Clerk issues for an active session and sends with each request to authenticate the caller. It is short-lived by design (about 60 seconds by default) and the Clerk SDK refreshes it automatically, so a leaked token is only briefly useful.
The token carries standard JWT claims and Clerk-specific ones: sub (the user id), sid (the session id), iss (the issuer, your Frontend API URL), exp / iat / nbf (timing), and azp (the authorized party, i.e. the origin it was minted for). When an organization is active, it also includes the organization id, role, and slug. You can add custom claims via a JWT template.
A user is the person or account. A session is one authenticated instance of that user on a device or browser; a user can have several sessions at once. An organization is a workspace or tenant the user belongs to. A session has at most one active organization, while a user can be a member of many.
Short lifetimes limit the blast radius if a token leaks. Durable login lives in the session itself (and the session cookie), not in the token, so Clerk can transparently mint a fresh token whenever the old one expires without signing the user out.
Call auth() from @clerk/nextjs/server inside Server Components, Route Handlers, and middleware. It returns the session claims (userId, sessionId, orgId, getToken, and helpers like has()) without a network call. To load the full user profile, call currentUser().
auth() reads claims directly from the verified session token, so it is fast and does no network round-trip. currentUser() calls Clerk's Backend API to fetch the complete, current User object, which costs a request. Use auth() for ids and authorization checks; use currentUser() when you need profile data.
getToken() mints a JWT you can forward to your own backend or a third-party service. Called with a template name, getToken({ template }) returns a token shaped by that JWT template's custom claims; called without one it returns the default session token.
useAuth() gives ids, the active org, and helpers (has, getToken, signOut). useUser() returns the full user profile. useSession() exposes the active session and its expiry. useClerk() returns the Clerk singleton for imperative actions like opening modals or switching the active session.
They read Clerk's reactive client auth state and render their children only once Clerk has loaded and the condition holds. <SignedIn> / <SignedOut> gate on authentication; <Show when="signed-in"> is the equivalent with an explicit condition. Pair them with <ClerkLoading> to handle the pre-load moment so nothing flickers.
Public pages here are server-rendered (Next.js 16 Cache Components / PPR), so search engines and AI crawlers receive real HTML without running JavaScript. Live, user-specific data (your decoded JWT and session) renders client-side once you sign in, while the reference text stays in the initial HTML.
No. clerkdev.app is an independent, unofficial demo built on Clerk. It is not affiliated with, endorsed by, or operated by Clerk, and Clerk is a trademark of its owner. It exists to show what a real Clerk session contains and how Clerk pairs with modern Next.js and React.
see it live