I couldn’t find Better Auth in Go, so I built one

Brian Iyoha — Tue, 28 Apr 2026 20:26:35 +0000

There’s been a noticeable shift in how authentication is approached in modern apps. Tools like Better Auth have pushed toward a model that is both developer-friendly and production-aware, with a strong emphasis on correctness, extensibility, and sensible defaults.

But if you’re working in Go, that experience hasn’t really existed.

That gap is what led to Limen.

What Limen is

Limen is a composable authentication library for Go, designed to integrate directly into your application rather than sit beside it as a separate service.

It is open source, publicly released, and available here:

The goal is to make authentication easier to add to Go backends without forcing you into a specific framework or application structure.

Why I built it

Go has no shortage of authentication libraries. There are JWT helpers, OAuth clients, and frameworks that cover parts of the problem. But most of them fall into one of two categories:

Low-level primitives that require significant assembly
Opinionated frameworks that are hard to extend or adapt

What’s often missing is a composable, production-ready system that:

Handles sessions, cookies, and OAuth
Lets you extend behavior without rewriting core logic
Doesn’t force you into a specific router or framework
Works with your existing database setup

This is the space Better Auth occupies in the JavaScript ecosystem. The goal with Limen is not to replicate it exactly, but to bring that level of design and usability into Go.

How Limen works

Limen is built around a plugin-first approach.

Instead of shipping every auth method as one large package, auth methods live as separate Go modules. You import the pieces you need and leave out the ones you do not.

For example, a basic setup can use the core package, a database adapter, and the credential/password plugin:

go get github.com/thecodearcher/limen
go get github.com/thecodearcher/limen/adapters/gorm
go get github.com/thecodearcher/limen/plugins/credential-password

Then you configure Limen inside your Go app:

auth, err := limen.New(&limen.Config{
    BaseURL:  "http://localhost:8080",
    Database: gormadapter.New(db),
    Plugins: []limen.Plugin{
        credentialpassword.New(),
    },
})

And mount it with your existing HTTP setup:

mux := http.NewServeMux()
mux.Handle("/api/auth/", auth.Handler())

That is the main idea: Limen should fit into your app, not dictate it.

What it supports today

The first public release includes support for:

Credential/password authentication
10+ Social Sign-on providers (and growing)
Two-factor authentication
Session management
Built-in rate limiting
Database adapters

It works with anything that speaks http.Handler, including net/http, Gin, Chi, and Echo.

Bring your own stack

One thing I wanted to avoid was building an auth system that assumes too much about the application around it.

Limen is designed to work with your existing Go backend.

You bring your own database. You bring your own framework. You choose the plugins you need.

That makes it useful whether you are building a small API, a SaaS backend, or something more custom.

Why not just use a hosted auth provider?

Hosted auth providers are great for many teams.

But sometimes you want authentication to live inside your own application. Maybe you want more control over the data model. Maybe you want to keep your backend self-contained. Maybe you just prefer owning that part of your stack.

Limen is for that kind of project.

It gives you a foundation without making auth feel like a separate product bolted onto your app.

Current state

Limen is ready to use today and still improving. That means the API will continue to evolve, the documentation will get better, and more plugins and adapters will be added over time.

You can check it out here:

What really is the difference between session and token based authentication

Brian Iyoha — Sun, 13 Jan 2019 00:05:04 +0000

A friend who is just getting into using Nodejs for backend development asked me to explain the difference between using session and jwt. So I thought I’d write this for any other person trying to understand what it means when you hear other developers talk about sessions and token based authentication.

Quick Introduction

Firstly, let’s talk about the HTTP (HyperText Transfer Protocol). From a quick Google search we get that:

HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands.

From the above definition, we can tell that HTTP is what enables communication between a client (frontend) and a server (backend). HTTP is stateless so each request made is totally unaware of any action taken previously. Say for example we just logged into our twitter account and we navigate to our settings page, with the default HTTP behavior, we would be required to log back in again because the server has no idea that we just logged in but with session and token authentication we can tell the server that we are already logged in and we have should be granted access to that page.

What is session based authentication?

Session based authentication is one in which the user state is stored on the server’s memory. When using a session based auth system, the server creates and stores the session data in the server memory when the user logs in and then stores the session Id in a cookie on the user browser.
The session Id is then sent on subsequent requests to the server and the server compares it with the stored session data and proceeds to process the requested action.

What is token based authentication?

Token based authentication is one in which the user state is stored on the client. This has grown to be the preferred mode of authentication for RESTful APIs. In the token based authentication, the user data is encrypted into a JWT (JSON Web Token) with a secret and then sent back to the client.
The JWT is then stored on the client side mostly localStorage and sent as a header for every subsequent request. The server receives and validates the JWT before proceeding to send a response to the client.

headers:{
"Authorization": "Bearer ${JWT_TOKEN}"
}

A typical example of how the token is sent with the header to the server

When to use?

There really isn’t a preferred method for authentication, both methods can be used interchangeably or together to create a hybrid system. It all boils down to the developer and the use case.
However, it is worth noting that token based authentication scales better than that of a session because tokens are stored on the client side while session makes use of the server memory so it might become an issue when there is a large number of users using the system at once.

Forem: Brian Iyoha