AuthKit's repository description names Radix and its dependency list does not, and the repo itself is a private example with no releases

The description names Radix and the dependency list does not

The repository description reads: the world's best login box powered by WorkOS and Radix.

The dependency list names WorkOS twice and does not mention Radix. It is six entries:

"@workos-inc/authkit-nextjs": "^4.3.0",
"@workos-inc/node": "^10.8.0",
"jose": "^5.2.3",
"next": "16.2.12",
"react": "^19.2.0",
"react-dom": "^19.2.0"

Two of those matter more than Radix's absence. `@workos-inc/authkit-nextjs` at ^4.3.0 is the actual AuthKit SDK, and this repository consumes it rather than containing it. `@workos-inc/node` is the WorkOS API client for the headless path. So the login box in the description is delivered by a dependency, and what lives in `src/` is the demonstration.

Radix may well be used inside the SDK rather than here, in which case the description is describing the rendered result rather than the manifest. Either way, the description is not a description of this tree.

The version fields make the same point. `"name": "authkit"`, `"version": "0.1.0"`, and `"private": true`. Combined with the absence of any GitHub release, this is an unpublished sample project under an MIT licence, not a distributed package.

There is no test script and no test directory

The scripts block has four entries and they are the Next.js defaults:

"dev": "next dev",
"build": "next build",
"start": "next start",
"lint": "eslint"

There is no `test` entry. There is also no test directory in the top-level listing, which is .env.local.example, .gitignore, .npmrc, .prettierrc, CODE_OF_CONDUCT.md, LICENSE, README.md, context7.json, eslint.config.mjs, next.config.js, package-lock.json, package.json, src/, tsconfig.json.

So the two authentication paths in this repository have no automated verification of any kind, in either this repo or in the example apps it links. That is a reasonable choice for a sample whose job is to be read, and an unreasonable one to inherit: the redirect callbacks, the environment variables and the two different session strategies are exactly the places where a copy of this example silently breaks when a dependency moves.

What little checking exists is linting. `eslint` is invoked with no path, so under the flat config in eslint.config.mjs it walks the project. Prettier is configured separately through .prettierrc, and `next.config.js` and `tsconfig.json` are the only other build inputs.

Seven localhost callbacks must be registered in the dashboard before anything renders

Step three of the setup is longer than it looks, because seven separate redirect URLs have to be pasted into the WorkOS dashboard. Four belong to the custom UI example, one per identity provider plus single sign-on:

http://localhost:3000/using-your-own-ui/sign-in/google-oauth/callback

http://localhost:3000/using-your-own-ui/sign-in/microsoft-oauth/callback

http://localhost:3000/using-your-own-ui/sign-in/github-oauth/callback

http://localhost:3000/using-your-own-ui/sign-in/sso/callback

Three more belong to the hosted example, one per variant: `/using-hosted-authkit/basic/callback`, `/using-hosted-authkit/with-session/callback` and `/using-hosted-authkit/with-nextjs/callback`.

Two consequences follow. The hosted side is not one example but three, distinguished by how the session is handled, and each needs its own entry. And every path is namespaced by which example directory you are running, so deleting an example leaves stale redirects pointing at routes that no longer exist rather than at an error you would notice locally.

All seven are plain HTTP on port 3000. The README gives no production equivalent; the only production guidance anywhere in the file is about pointing the hosted UI at your own domain.

The two examples differ in one thing: who hosts the login form

The repository holds two example apps under `src/app/`, and the README is explicit that there are two ways to use AuthKit.

The hosted example is described as the fastest route, with a fully themeable hosted UI that handles all of the authentication flows. The trade is stated rather than hidden: when you go to production you can point it at a custom domain of the form `auth.yourapp.com` so it matches your application. So the hosted path gives you the flows and takes the domain.

The custom example uses the features of AuthKit while building the UI yourself, by integrating directly with the headless WorkOS User Management APIs. That authentication UI is self-hosted in your application. You own the markup, the styling and the deployment, and you own the work of implementing the flows the hosted version would have given you.

Neither is a library API. Both are applications that call one: either the AuthKit SDK or the WorkOS client, depending on the route. The SDK dependency is present in the manifest for the hosted path, and the headless client is what the custom path talks to.

Having both implemented in one repository is the reason to read it. The hosted variant names three session strategies, basic, with-session and with-nextjs, which is the part a single example would have hidden.

Both routes need a hosted account and a secret key on your machine

The prerequisites section is one line: you will need a WorkOS account, linked to the signup page on the dashboard.

That is the dependency that decides whether this suits you. Nothing in this repository runs locally in the sense of a self-contained server; the examples are front ends that redirect to a hosted identity provider and receive callbacks. Deleting your WorkOS project breaks both examples, and the WorkOS dashboard is where the client id, the secret key and the redirect list all live.

Setup step two makes that concrete. You sign into the dashboard, go to API Keys, and copy the Client ID and the Secret Key, then rename `.env.local.example` to `.env.local` and fill in two values:

WORKOS_CLIENT_ID="<your Client ID>"
WORKOS_API_KEY="<your Secret Key>"

The example file is committed and the real one is not, which is the correct arrangement and the only secret handling the repository does. There is no other credential in the tree and no server-side key.

The run commands are `npm install`, then `npm run dev`, then open `http://localhost:3000`. Port 3000 is assumed throughout, including in the seven callback URLs, so anything else needs the dashboard entries changed to match.

The homepage field and the documentation link point at two different domains

The homepage recorded for the repository is https://authkit.com. The only documentation link in the README is to the WorkOS user management documentation, at workos.com/docs/user-management, behind an Explore the docs link.

So the repository metadata and the README point at two different places, and neither is a page in this repository. There is no docs directory in the top-level listing and no README section describing the API surface. The README itself is 232 words, and essentially all of it is setup: two ways to use AuthKit, one prerequisite, and four numbered steps.

What a reader gets for those 232 words is the sequence of manual steps in full, including the seven redirect URLs. What they do not get is any statement of what AuthKit is at the protocol level, what the session handling differences are between the three hosted variants, or how errors are reported.

For an authentication component, that is a thin README. The hosted UI in particular is described in adjectives, themeable and handles all of your flows, with the concrete detail pushed to a site the repository does not contain.

Compare that with the two files in the tree that are not application code at all: `context7.json`, which describes the project for documentation tools that feed context to code assistants, and CODE_OF_CONDUCT.md.

The tree is an example repository, and it says so in its metadata rather than its prose

Reading the tree alongside the README settles the question of what this repository is.

There is no test directory and no CONTRIBUTING.md. There is a CODE_OF_CONDUCT.md, an `.npmrc`, a lockfile and an eslint flat config. The application code is under `src/`, and the two examples referenced from the README are `src/app/using-hosted-authkit` and `src/app/using-your-own-ui`.

The publishing fields are the clearest signal. `"private": true` means npm publish would refuse it, `"version": "0.1.0"` is a placeholder rather than a scheme, and there are no GitHub releases to pin against. Versions in the repository are the dependencies': `next` and `eslint-config-next` are both pinned to exactly 16.2.12 while React and the WorkOS packages float on carets.

So a team adopting this is copying an example, not depending on a version. That is a legitimate and common pattern, and it is worth being explicit about which one you are doing: the login flow will be yours to maintain, and the SDK it calls will move under you on its own schedule.

The alternative is to depend on `@workos-inc/authkit-nextjs` directly and skip this repository entirely.

Editorial conclusion

AuthKit is worth reading if you are choosing between a hosted login flow and building one on headless APIs, because the repository implements both side by side and the difference is mostly about who hosts the UI. It is not worth installing as a dependency: the code here is an unpublished example, the library is a separate npm package, and nothing in this repository is versioned or released. Before starting, confirm you are willing to depend on a hosted WorkOS account, since both examples require dashboard credentials and seven registered localhost callbacks before anything renders.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. workos/authkit on GitHub