React Auth Kit: JWT session state for React apps, with the token lives on the client

The library's job is client-side JWT state, not token issuance

React Auth Kit is described as a library for React that makes token based authentication with JSON Web Tokens straightforward. The scope is narrow and worth stating precisely: the library does not issue tokens, does not talk to your identity provider, and does not know what your users are. It manages the client half of the flow.

What that means in practice is that your server still does the credential check, still returns a signed token, and still decides what the token contains. The library takes that token, stores it, and makes the stored state available to your components through hooks. It also handles the parts every hand-rolled implementation gets subtly wrong, like clearing state on logout and guarding routes that should not render for anonymous visitors.

The project presents itself as lightweight, typed and written in TypeScript, and the README positions it as usable with React itself, Next JS, Gatsby, React Router and Remix. That list of integrations is a hint about the design. The library sits above the router and the data layer rather than replacing them, so it fits a project that already has a routing and server-state setup.

The token lives in the browser, and that is the design

The README lists secure client side authentication among the features, and the topic tags include jwt and jwt-authentication. It is worth being clear about what client side authentication means here, because the security of the whole scheme rests on it.

A JSON Web Token is a bearer credential. Whoever holds the token is the user, for as long as the token is valid, and the client is the holder by construction. Any library that keeps a JWT in a browser application is therefore keeping a credential where a page script can read it. React Auth Kit does not hide this or pretend otherwise, it simply packages the handling of it: store, read, refresh, clear.

The consequence for an adopter is that the security of your application still depends on how you issue that token. Short lifetimes, proper audience and issuer claims, and a revocation story that does not rely on the client are all server-side decisions. The library saves you the client plumbing and none of the server risk.

This is also why the alternative worth naming is a server-side session with an HTTP only cookie. That approach keeps the credential out of JavaScript entirely, at the cost of CSRF handling and the statefulness you get back. The choice is architectural, and React Auth Kit is a reasonable pick for the JWT side of it.

A lerna and nx monorepo, with the package published separately

The repository layout explains a lot about how the project is organised. The root package.json declares npm workspaces over packages/*, and the build and test commands are driven by lerna and nx:

    "build": "npx lerna run build",
    "test": "npx lerna run test",

The same manifest shows the supporting tooling: eslint with a flat config, testing-library for React, jest and the jest plugin, husky for git hooks, and commitlint with the conventional config. The docs get their own check, a markdownlint run over the docs folder with the repository's markdownlint config, which means documentation style is enforced in the same workflow as the code.

The root manifest also names the published package react-auth-kit, with an engines field requiring node 16 or newer, a description of it as an authentication library for React that makes token based auth easy, and the MIT licence. The workspace layout means the library and the example applications are developed together, and the examples directory holds separate projects for a Next JS route setup, a Create React App refresh token example, a Create React App TypeScript example, a plain Create React App example and a Vite example. Those five examples are the most useful part of the repository for a new user, because each one shows the same library wired into a different build tool.

The documentation is a separate mkdocs site

The project documentation is not in the README. The repository root contains an mkdocs.yml, and a pyproject.toml that declares a project named react-auth-kit requiring Python 3.11 or newer with mkdocs-material as its only dependency, plus a uv.lock. A Python project in a TypeScript library is not a mistake, it is the docs toolchain, since mkdocs is a Python static site generator and the docs are written in markdown alongside the code.

That is a reasonable choice for a project that wants versioned, searchable documentation with a themed layout, and it has a cost: you need a Python environment to build the docs locally, separate from the Node one you need for the library itself. The uv.lock and the .python-version file at the root pin that environment, so the setup is reproducible once you know it exists.

The published documentation site lives at authkit.arkadip.dev, and the README links it as the main entry point. The docs directory in the repository is the source for that site, and the documentation in it is what the markdownlint script checks.

Version numbers in the repository do not line up with the tags

The maintenance picture needs care, because the version recorded in the repository and the version recorded in the release history are different numbers.

The root package.json declares version 2.12.7. The published releases are v3.1.3 from 2024-03-20, v3.1.1 from 2024-02-15 and v3.1.0 from 2024-02-13. So the tags are ahead of the version in the manifest at the repository root, which is a sign that the published package is versioned from a workspace package under packages/ rather than from the root, and that the root manifest is not the source of truth for the published version.

What is clear is the timeline. The last three releases are all from the first quarter of 2024, while the last push to the master branch was on 2026-10-13. The project is not archived and the branch is still receiving work, but no new tag has appeared since March 2024. Whether that means the recent commits are fixes on the way to a new release or work on something else is not something the repository states.

For a user picking a version, the practical consequence is to read the changelog rather than infer from the root manifest. The repository has both a CHANGELOG.md and a CHANGELOG-OLD.md, which suggests the current release line is documented separately from the earlier history.

What a security review of this library would ask

Because the credential handling is client side, the questions a reviewer should ask are specific rather than general. Where is the token stored, and is it in a place a script can read? Is there a refresh path, and if so, does the refresh token have a longer life than the access token in a way that makes it the more valuable target? What happens to the stored credential on logout, on token expiry, and on a failed refresh?

The examples directory answers part of this. A dedicated create-react-app-refresh-token example exists, which tells you the refresh flow is a first class part of the library's story rather than something left to the user. The Next JS example is about route protection, which is the other half of the job.

The remaining risk sits outside the library. The token has to be issued with claims that make it useless elsewhere, and the backend has to decide what an expired or revoked token means. A client-side library can make the wrong state easy to fix in the UI, and it cannot make a badly scoped token safe. The README lists secure client side authentication as a feature, and the honest reading is that the library is careful about its half of the boundary.

Editorial conclusion

Adopt React Auth Kit if you are building a React application with a JSON Web Token backend and want login state, logout and protected routing without hand-rolling the storage and refresh plumbing. Do not adopt it if your authorisation model is server-side session cookies, because the library is built around a token held in the browser. Before you build on it, confirm the version you install matches the API you are reading about, since the repository root manifest still reads 2.12.7 while the published tags reach v3.1.3, and the last push was on 2026-10-13 with no release newer than March 2024.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. react-auth-kit/react-auth-kit on GitHub
4. README
5. Releases