DEV Community: karabo seeisa

Building a Secure Auth System in Express (JWT, Redis, Refresh Tokens, and RBAC) and Automating It with a CLI

karabo seeisa — Sat, 04 Apr 2026 07:46:19 +0000

Authentication in Express applications is often underestimated.

Most implementations stop at “generate a JWT and verify it,” but real-world systems require much more:

• Refresh token rotation

• Token invalidation

• Concurrency safety

• Role-based access control (RBAC)

• Stateful tracking (usually via Redis)

After building this stack multiple times, I decided to formalise it into a reusable system and eventually a CLI that scaffolds it in seconds.

This post breaks down the architecture behind it and how you can use it.

The Problem with Typical JWT Auth

A basic JWT setup usually looks like this:

TypeScript

const token = jwt.sign(user, secret, { expiresIn: "15m" });

This works for simple cases, but breaks down quickly:

No Token Revocation

Once issued, a JWT is valid until it expires.

You can’t easily invalidate it.

Stateless Refresh = Security Risk

If refresh tokens are not tracked, they can be reused indefinitely.

Concurrency Issues

If two refresh requests happen at the same time:

both can succeed

multiple valid tokens are created

This leads to token duplication and potential session abuse.

The Architecture I Settled On

To solve these issues
, the system uses:

Access Tokens (JWT)

• Short-lived (e.g. 15 minutes)

• Used for API authentication

• Stateless verification

Refresh Tokens (Stateful)

• Stored in Redis

• Rotated on every use

• Old tokens are invalidated

This gives you control over sessions.

Redis as a Token Store

Redis acts as the source of truth for refresh tokens:

• Track active sessions

• Invalidate tokens instantly

• Enforce single-use refresh tokens

Refresh Token Rotation

Every refresh request:

• Verifies the token

• Checks Redis for validity

• Deletes the old token

• Issues a new refresh token

This ensures:

A refresh token can only be used once.

Concurrency Safety

A key problem is handling simultaneous refresh requests.

Solution:

• Atomic operations in Redis

• Only one request can invalidate + rotate

• The second request fails with 401

This prevents replay attacks and token duplication.

RBAC (Role-Based Access Control)

Authentication is not enough , you also need authorization.

Example middleware:

TypeScript

app.get("/admin", auth.requireAdmin, (req, res) => {

res.json({ message: "Admin only" });

});

This ensures only users with the correct role can access protected routes.

Putting It Together
The system exposes a simple interface:

TypeScript:

const auth = await createAuthenik8({

jwtSecret: process.env.JWT_SECRET!,

refreshSecret: process.env.REFRESH_SECRET!,

});

From there:

signToken() → access tokens

generateRefreshToken() → refresh tokens

Refresh token() → rotation logic

requireAdmin → RBAC middleware

Automating the Setup
After building this repeatedly, I created a CLI to remove the setup step entirely:

Bash

npx create-authenik8-app my-app

This generates:

• Express + TypeScript project

• JWT + refresh token system

• Redis integration

•RBAC middleware

• Preconfigured routes

You can go from zero → running auth server in minutes.

Why Redis is Required
A common question is: “Why not keep everything stateless?”

Because:

• You can’t revoke tokens

• You can’t prevent reuse

• You can’t track sessions

Redis enables:

• Immediate invalidation

• Session tracking

• Single-use refresh tokens

Trade-offs

This approach introduces:

• External dependency (Redis)

• Slight complexity increase

• Network latency for token validation

But in exchange, you get:

• Proper session control

• Stronger security guarantees

• Predictable auth behavior

Final Thoughts

Authentication is one of those systems that seems simple until it isn’t.

The difference between a basic implementation and a production-ready one is:

• handling edge cases

• controlling state

• preventing abuse

This project started as a way to standardize those decisions and avoid rewriting the same logic repeatedly.

If you’ve built auth systems before, I’d be interested in how you approach:

refresh token handling
revocation strategies
concurrency edge cases

Links:
Authenik8 site:https://authenik8.vercel.app/

Gitlab: https://gitlab.com/COD434/create-authenik8-app

Tiktok: https://www.tiktok.com/@thesbd8?\_r=1&\_t=ZS-9577WVfucT4

Try It

Bash

npx create-authenik8-app my-app

Closing

If you’re working with Express and need a solid starting point for authentication, this should save you a significant amount of setup time.

Feedback is welcome.

RabbitMQ: The Superhero My API Didn’t Know It Needed

karabo seeisa — Mon, 28 Jul 2025 13:20:16 +0000

The Problem: Hanging Requests, Delivered Emails

In my Node.js API, users register and receive a verification email. Simple, right?

But something strange kept happening:

The email would be sent
But the HTTP request would hang
The client got no response
My logs showed timeouts
And eventually… crashed sockets

After digging, I realized:

The SMTP email-sending process was blocking the main thread just long enough to let the HTTP connection time out.

This was a race condition: my API was waiting for the SMTP server to respond, while the client’s connection was waiting for me.

The Insight: Decouple the Work

I realized I was making the email-sending part synchronous, tying the API response to something slow (SMTP).

That’s when I remembered the concept of queuing so I did some research and found that personally I liked RabbitMQ.

How I Fixed This Issue

Here’s what I did:

The /register route publishes a message to a RabbitMQ queue (emailQueue)
A separate email worker subscribes to the queue
The worker handles the SMTP email process asynchronously
Meanwhile, the API responds immediately to the client

Here's What Achieved:

No more hanging sockets
Emails still go out
Race condition avoided
Clean separation of concerns

Why I Chose RabbitMQ?

I could’ve tried background threads or retry logic. But RabbitMQ gave me:

Message durability
Retry control
A proper job queue
A decoupled architecture I can scale later

And now, I can apply this same technique for:

Password resets
Event logs
Audit trails
Even SMS messages or 2FA

Call me a nerd but I think that's cool.

Implementation:

This is the publisher - gets the request to send a verification email, drops it into a queue, and the worker handles the rest . simple, fast, and scalable.

export const publishToQueue = async (queue: string, message: any)=>{
if(!channel)
throw new Error("RabbitMQ channel not initialized");
channel.sendToQueue(queue,Buffer.from(JSON.stringify(message)),{persistent: true});
}

This is the worker - It consumes messages form the queue and sends the email asynchronously,without delaying the HTTP response to the client .

That means users don't wait around for an email to send = much better UX if you ask me

channel.consume("emailQueue",async (msg) =>{
if(msg !== null){
const {email,verifyToken} = JSON.parse(msg.content.toString())
await sendVerificationEmail(email,verifyToken);
channel.ack(msg)
}
})

Final Thoughts

If your API does more than just respond to users — like sending emails or talking to 3rd parties — don’t make it wait.

RabbitMQ helped me move that responsibility out of the request cycle and made my code faster, safer, and easier to maintain.

I also plan to use it in the near future.

Let’s Connect

Have you hit similar issues in your backend? let me know how you tackled async tasks or race conditons.

Here's how I implemented it might spark something in your project :Github

A Plug and Play Auth API

karabo seeisa — Sun, 13 Jul 2025 14:39:58 +0000

From "Simple Form" to Full Pure Backend Auth API—Here’s What I Learned

I thought building a form would be easy. Spoiler: I was wrong.

What started as a basic CRUD app quickly spiraled into a deep dive into:

✔️ Token-based authentication (JWT)

✔️ Password hashing & encryption

✔️ Role-based access control

✔️ Redis-rate-limiting
And some other cool features

Turns out, the "Login with Google" button I mindlessly click every day? Way more complex under the hood.

I built this Auth API to demystify the process with security, docs, and scalability in mind. Perfect for devs who:

🔹 Want to see auth workflows stripped bare

🔹 Need a reference for their next project

Check it out & roast my code: (https://github.com/COD434/Auth-System-API)

Question for you:
What’s the most "simple" feature that surprised you with its complexity?