DEV Community: Brian Iyoha

Build multi-tenant auth in Go with Limen

Brian Iyoha — Tue, 11 Aug 2026 14:00:04 +0000

Many SaaS products are organized around workspaces, teams, or customer accounts. In those apps, authentication is only one part of the tenancy model. You also need a way to create organizations, manage membership, switch the active workspace, scope data to the right tenant, and decide what each member can do.

In this guide, each organization acts as a tenant. The same user may belong to several organizations, and each organization has its own projects, members, invitations, roles, and product data. For each organization-scoped action, you need to know:

a signed-in user
the organization they are working in
whether their role allows the action.

Limen's Organization plugin gives your Go app the pieces for that flow: organizations, members, roles, invitations, organization switching, and Go APIs for tenant-aware handlers.

We'll use projects as the running example: each project is created inside the user's selected organization.

What we are building

The app will support:

email/password sign-up and sign-in
organizations as tenants
switching between a user's organizations
organization invitations
tenant-owned project data scoped by organization
tenant-scoped roles: owner, admin, and member
app-specific permissions such as project:create
a protected Go endpoint that refuses to create a project unless the current user can do it in the selected organization.

You'll need Go 1.25+ and Postgres. If you want to follow the frontend snippets, you'll also need Node 20+.

If you want a local database quickly:

docker run --name limen-pg -e POSTGRES_PASSWORD=postgres -p 5432:5432 -d postgres

Create a new Go module and install Limen, the SQL adapter, email/password auth, and organizations:

mkdir limen-multitenant && cd limen-multitenant
go mod init example.com/limen-multitenant

go get github.com/thecodearcher/limen
go get github.com/thecodearcher/limen/adapters/sql
go get github.com/thecodearcher/limen/plugins/credential-password
go get github.com/thecodearcher/limen/plugins/organization
go get github.com/lib/pq

Wire Limen into a Go server

Create main.go:

package main

import (
    "context"
    "database/sql"
    "encoding/json"
    "log"
    "net/http"
    "os"

    _ "github.com/lib/pq"

    "github.com/thecodearcher/limen"
    "github.com/thecodearcher/limen/access"
    sqladapter "github.com/thecodearcher/limen/adapters/sql"
    credentialpassword "github.com/thecodearcher/limen/plugins/credential-password"
    organization "github.com/thecodearcher/limen/plugins/organization"
)

func main() {
    db, err := sql.Open("postgres", os.Getenv("DATABASE_URL"))
    if err != nil {
        log.Fatal(err)
    }
    defer db.Close()

    auth, err := newAuth(db)
    if err != nil {
        log.Fatal(err)
    }

    orgAPI := organization.Use(auth)

    mux := http.NewServeMux()
    mux.Handle("/auth/", auth.Handler())
    mux.HandleFunc("POST /api/projects", createProject(auth, orgAPI))

    log.Println("listening on :8080")
    log.Fatal(http.ListenAndServe(":8080", mux))
}

func newAuth(db *sql.DB) (*limen.Limen, error) {
    ac := access.New(access.MergeStatements(
        organization.DefaultStatements(),
        access.Statements{
            "project": {"create", "read", "update", "delete"},
            "billing": {"read", "update"},
        },
    ))

    roles, err := tenantRoles(ac)
    if err != nil {
        return nil, err
    }

    return limen.New(&limen.Config{
        Database: sqladapter.NewPostgreSQL(db),
        CLI:      &limen.CLIConfig{Enabled: true},

        Plugins: []limen.Plugin{
            credentialpassword.New(),
            organization.New(
                organization.WithAccessControl(ac),
                organization.WithRoles(roles...),
                organization.WithSlugNormalization(true),
                organization.WithMaxOrgPerUser(5),
                organization.WithSendInvitationMail(func(ctx context.Context, data *organization.SendInvitationMailData) {
                    inviteURL := "http://localhost:3000/invitations/" + data.Invitation.Token
                    log.Printf("invite %s to %s: %s", data.Invitation.Email, data.Organization.Name, inviteURL)
                }),
            ),
        },
    })
}

func tenantRoles(ac *access.AccessControl) ([]access.Role, error) {
    owner, err := organization.DefaultOwnerRole(ac, access.P("project:*", "billing:*"))
    if err != nil {
        return nil, err
    }

    admin, err := organization.DefaultAdminRole(ac, access.P("project:*", "billing:read"))
    if err != nil {
        return nil, err
    }

    member, err := organization.DefaultMemberRole(ac, access.P("project:read"))
    if err != nil {
        return nil, err
    }

    return []access.Role{owner, admin, member}, nil
}

Two plugins do most of the setup:

credentialpassword.New() handles sign-up and sign-in.
organization.New(...) handles tenants, memberships, invitations, roles, and organization switching.

The role setup also includes the application actions we want to protect: project and billing. That lets organization roles grant access to product features, not only organization management.

Then we extend the default organization roles:

owner can do everything in the organization, plus all project and billing actions
admin can manage projects and read billing
member can read projects only.

Those permissions are scoped per organization. A user can be an owner in one organization and only a member in another.

Protect product actions

Limen handles authentication and organization management. For product actions like creating a project, your Go code should confirm which organization the user is working in, check the permission, and keep the project inside that organization.

The pattern is:

Require a signed-in user with auth.GetSession(r).
Find the organization the user is working in.
Check the required permission with orgAPI.HasPermission(...).
Create or read records only inside that organization.

Add this below tenantRoles:

func createProject(auth *limen.Limen, orgAPI organization.API) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        session, err := auth.GetSession(r)
        if err != nil {
            http.Error(w, "Unauthorized", http.StatusUnauthorized)
            return
        }

        organizationID, err := orgAPI.GetActiveOrganizationID(r.Context(), session.Session)
        if err != nil || organizationID == nil {
            http.Error(w, "Select an organization first", http.StatusBadRequest)
            return
        }

        if err := orgAPI.HasPermission(r.Context(), session.User, organizationID, access.P("project:create")); err != nil {
            http.Error(w, "Forbidden", http.StatusForbidden)
            return
        }

        var body struct {
            Name string `json:"name"`
        }
        if err := json.NewDecoder(r.Body).Decode(&body); err != nil || body.Name == "" {
            http.Error(w, "Project name is required", http.StatusBadRequest)
            return
        }

        // Persist the project with organizationID in your own app database.
        project := map[string]any{
            "name":            body.Name,
            "organization_id": organizationID,
        }

        w.Header().Set("Content-Type", "application/json")
        w.WriteHeader(http.StatusCreated)
        json.NewEncoder(w).Encode(project)
    }
}

For project creation, tenant scoping belongs to the app API. The frontend sends the project name, and POST /api/projects creates it in the organization the user is working in.

For list and update endpoints, use the same pattern:

if err := orgAPI.HasPermission(ctx, session.User, organizationID, access.P("project:read")); err != nil {
    return err
}

// SELECT * FROM projects WHERE organization_id = organizationID

Run migrations

Enable the CLI with CLI: &limen.CLIConfig{Enabled: true} as shown above. Then install the CLI:

go install github.com/thecodearcher/limen/cmd/limen@latest

Set your environment:

export DATABASE_URL="postgres://postgres:postgres@localhost:5432/postgres?sslmode=disable"
export LIMEN_SECRET="$(openssl rand -hex 16)"

Start the app:

go run .

Leave it running. In another terminal, generate migrations:

export DATABASE_URL="postgres://postgres:postgres@localhost:5432/postgres?sslmode=disable"
limen generate migrations --driver postgres --dsn "$DATABASE_URL"

Apply the generated SQL with your migration tool before using the app.

Set up the TypeScript client

Install the SDK in your frontend:

npm install limen-auth

Create src/auth-client.ts:

import { createAuthClient } from 'limen-auth/react'
import { credentialPasswordPlugin, organizationPlugin } from 'limen-auth/plugins'

export const auth = createAuthClient({
  baseURL: 'http://localhost:8080',
  plugins: [credentialPasswordPlugin(), organizationPlugin()],
})

The rest of the frontend calls in this guide use that auth client.

Create a user and organization

Create the user with the credential-password plugin:

import { auth } from './auth-client'

await auth.signUp.credential({
  email: 'ada@example.com',
  password: 'Correct-horse-1',
})

Now create an organization:

const organization = await auth.organization.create({
  name: 'Acme',
  slug: 'acme',
})

Creating an organization does three things:

creates the organization
makes the current user a member
gives that user the owner role.

After creation, the user is working in that organization.

Switch between tenants

A user can belong to multiple organizations. List the organizations they belong to:

const organizations = await auth.organization.list()

Switch to another organization:

await auth.organization.switch({ id: organization.id })

Only members can switch into an organization. Pass null to clear the selected organization:

await auth.organization.switch({ id: null })

Now create a project through your app API. The Limen SDK handles auth state, and /api/projects belongs to your app:

async function createProject(name: string) {
  const response = await fetch('http://localhost:8080/api/projects', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ name }),
  })

  if (!response.ok) {
    throw new Error(await response.text())
  }

  return response.json()
}

await createProject('Customer portal')

If the user has not selected an organization, they get 400. If they are working in an organization but lack project:create, they get 403. Otherwise, your handler can safely create the project under the selected organization.

Invite teammates

Owners and admins can invite people into the organization they are working in:

await auth.organization.invite({
  email: 'grace@example.com',
  role: 'member',
})

When an invitation is created, the server example logs a local invite URL. In production, send the invite link with your email provider.

The invited user signs in with the invited email address and accepts:

const invitationToken = new URL(window.location.href).pathname.split('/').pop()
if (!invitationToken) throw new Error('Missing invitation token')

await auth.signIn.credential({
  credential: 'grace@example.com',
  password: 'Correct-horse-1',
})

await auth.organization.acceptInvitation({
  token: invitationToken,
})

After acceptance, the invited user joins with the selected role. They can then switch into the organization and use only the permissions that role grants:

const joinedOrganizations = await auth.organization.list()
await auth.organization.switch({ id: joinedOrganization.id })

Gate UI from the user's membership:

import { can } from 'limen-auth'
import { auth } from './auth-client'

export function CreateProjectButton() {
  const { data: membership, isPending } = auth.useActiveMembership()

  if (isPending) return null
  if (!can(membership, 'project:create')) return null

  return <button type="button">New project</button>
}

Use client checks to keep the interface tidy. Keep the real authorization in Go with orgAPI.HasPermission(...).

Where to go next

This guide keeps the example small: users, organizations, invitations, switching, projects, and role checks.

For the full organization API, see the Organization plugin docs.

For integrations and automation, add the API Key plugin and the organization-scoped API key flow.

Full-stack auth in Go and React: email + password with Limen

Brian Iyoha — Tue, 07 Jul 2026 19:53:13 +0000

When Limen launched, the TypeScript client was still on the roadmap. It's here now: limen-auth, a typed client for your Limen server with first-class adapters for React, Vue, Svelte, and Solid.

This post builds a full-stack auth flow: email/password sign-up and sign-in, a session-aware UI, and email verification.

Backend: a Go server running Limen with the credential-password plugin and Postgres
Frontend: a Vite + React app using limen-auth

You'll need Go 1.25+, Node 20+, and a Postgres database. If you have Docker, this gets you one:

docker run --name limen-pg -e POSTGRES_PASSWORD=postgres -p 5432:5432 -d postgres

Part 1: The Go server

Install

Create a new module and pull in Limen, the SQL adapter, and the credential-password plugin:

mkdir limen-app && cd limen-app
go mod init example.com/limen-app

go get github.com/thecodearcher/limen
go get github.com/thecodearcher/limen/adapters/sql
go get github.com/thecodearcher/limen/plugins/credential-password
go get github.com/lib/pq

Wire up the server

Create main.go:

package main

import (
    "database/sql"
    "encoding/json"
    "log"
    "net/http"
    "os"

    _ "github.com/lib/pq"

    "github.com/thecodearcher/limen"
    sqladapter "github.com/thecodearcher/limen/adapters/sql"
    credentialpassword "github.com/thecodearcher/limen/plugins/credential-password"
)

func main() {
    db, err := sql.Open("postgres", os.Getenv("DATABASE_URL"))
    if err != nil {
        log.Fatal(err)
    }
    defer db.Close()

    auth, err := limen.New(&limen.Config{
        BaseURL:  "http://localhost:8080",
        Database: sqladapter.NewPostgreSQL(db),
        CLI:      &limen.CLIConfig{Enabled: true}, // lets the limen CLI generate migrations

        HTTP: limen.NewDefaultHTTPConfig(
            // Allow the React dev server, which runs on a different origin.
            limen.WithHTTPTrustedOrigins([]string{"http://localhost:5173"}),
            // Local dev runs over plain HTTP; re-enable in production.
            limen.WithHTTPCookieSecure(false),
        ),

        Email: limen.NewDefaultEmailConfig(
            limen.WithEmailVerification(
                limen.WithSendEmailVerificationMail(func(email, token string) {
                    // Plug in your email provider here. For now, log the link.
                    log.Printf("verify %s: http://localhost:5173/verify-email?token=%s", email, token)
                }),
            ),
        ),

        Plugins: []limen.Plugin{
            credentialpassword.New(),
        },
    })
    if err != nil {
        log.Fatal(err)
    }

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

    log.Println("listening on :8080")
    log.Fatal(http.ListenAndServe(":8080", cors(mux)))
}

// cors lets the React dev server on :5173 call the API with credentials.
func cors(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        if r.Header.Get("Origin") == "http://localhost:5173" {
            w.Header().Set("Access-Control-Allow-Origin", "http://localhost:5173")
            w.Header().Set("Access-Control-Allow-Credentials", "true")
            w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization")
            w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS")
        }
        if r.Method == http.MethodOptions {
            w.WriteHeader(http.StatusNoContent)
            return
        }
        next.ServeHTTP(w, r)
    })
}

That's the auth server. credentialpassword.New() adds the email/password routes and auth.Handler() serves them under /auth, with password hashing, sessions, and the rest handled for you.

Note: The WithHTTP* options and the cors middleware are there only for cross-origin local dev: they let the browser send the session cookie from :5173 to :8080 over plain HTTP. In production you'd tighten the cookie flag and hand CORS to your framework's middleware.

The email callback logs the verification link for local development. In production, send that link through your email provider.

Set the environment before running:

export DATABASE_URL="postgres://postgres:postgres@localhost:5432/postgres?sslmode=disable"
export LIMEN_SECRET=$(openssl rand -hex 16)

Migrations

Limen ships a CLI that generates SQL migrations from your configured schema. Install it, run the server once so it writes the schema snapshot (.limen/schemas.json, add it to .gitignore), then generate and apply:

go install github.com/thecodearcher/limen/cmd/limen@latest

go run .   # once; Ctrl-C after it starts

limen generate migrations -d postgres -c "$DATABASE_URL" -o ./migrations

The CLI generates migration files; applying them is up to your usual tool. With golang-migrate:

migrate -path ./migrations -database "$DATABASE_URL" up

Start the server again with go run . and the backend is done. Verify it end to end with curl:

curl -i http://localhost:8080/auth/signup/credential \
  -H "Content-Type: application/json" \
  -d '{"email": "ada@example.com", "password": "Correct-horse-1"}'

You get back the new user, a Set-Cookie session, and a verification link in the server logs.

A protected route of your own

Your own endpoints can require a session with auth.GetSession(r), which reads and validates the session from any request. Add this inside main(), after the /auth/ mount, and restart the server:

mux.HandleFunc("GET /api/profile", func(w http.ResponseWriter, r *http.Request) {
    session, err := auth.GetSession(r)
    if err != nil {
        http.Error(w, "Unauthorized", http.StatusUnauthorized)
        return
    }
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(session.User)
})

GetSession works identically in middleware, in Gin handlers via c.Request, or anywhere else an *http.Request exists.

Part 2: The React app

Set up the client

Scaffold a Vite app next to the server and install the SDK:

npm create vite@latest limen-web -- --template react-ts
cd limen-web && npm install limen-auth

Create the client once and share it across the app. Create src/auth-client.ts:

import { createAuthClient } from 'limen-auth/react'
import { credentialPasswordPlugin } from 'limen-auth/plugins'

export const auth = createAuthClient({
  baseURL: 'http://localhost:8080',
  plugins: [credentialPasswordPlugin()],
})

baseURL is the server origin; the SDK's default basePath is /auth, which matches where we mounted the handler. Cookies are the default transport, and the client already sends credentials: 'include'.

Sign up

Create src/SignUpForm.tsx:

import { useState } from 'react'
import { LimenError } from 'limen-auth'
import { auth } from './auth-client'

export function SignUpForm() {
  const [email, setEmail] = useState('')
  const [password, setPassword] = useState('')
  const [error, setError] = useState<string | null>(null)

  async function onSubmit(e: React.FormEvent) {
    e.preventDefault()
    setError(null)
    try {
      await auth.signUp.credential({ email, password })
      // Signed in. The session store updates itself.
    } catch (err) {
      setError(err instanceof LimenError ? err.message : 'Something went wrong')
    }
  }

  return (
    <form onSubmit={onSubmit}>
      <input type="email" value={email} onChange={(e) => setEmail(e.target.value)} placeholder="Email" required />
      <input
        type="password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
        placeholder="Password"
        required
      />
      {error && <p role="alert">{error}</p>}
      <button type="submit">Create account</button>
    </form>
  )
}

Sign-up establishes a session on the server (auto sign-in is Limen's default), and the SDK writes it into its reactive session store. Any component watching the session re-renders on its own, so the form doesn't need redirect logic.

Sign in

Same shape. Create src/SignInForm.tsx:

import { useState } from 'react'
import { LimenError } from 'limen-auth'
import { auth } from './auth-client'

export function SignInForm() {
  const [email, setEmail] = useState('')
  const [password, setPassword] = useState('')
  const [error, setError] = useState<string | null>(null)

  async function onSubmit(e: React.FormEvent) {
    e.preventDefault()
    setError(null)
    try {
      await auth.signIn.credential({ credential: email, password })
    } catch (err) {
      setError(err instanceof LimenError ? err.message : 'Something went wrong')
    }
  }

  return (
    <form onSubmit={onSubmit}>
      <input type="email" value={email} onChange={(e) => setEmail(e.target.value)} placeholder="Email" required />
      <input
        type="password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
        placeholder="Password"
        required
      />
      {error && <p role="alert">{error}</p>}
      <button type="submit">Sign in</button>
    </form>
  )
}

Let the session drive the UI

auth.useSession() gives React a live view of the current session. It loads the session on mount and updates when the user signs in or out. Replace src/App.tsx:

import { useState } from 'react'
import { auth } from './auth-client'
import { SignInForm } from './SignInForm'
import { SignUpForm } from './SignUpForm'
import { Dashboard } from './Dashboard'
import { VerifyEmail } from './VerifyEmail'

export default function App() {
  const { data, isPending } = auth.useSession()
  const [mode, setMode] = useState<'signin' | 'signup'>('signin')

  // With a router, make this a route instead.
  if (window.location.pathname === '/verify-email') return <VerifyEmail />

  if (isPending) return <p>Loading…</p>
  if (data) return <Dashboard user={data.user} />

  return (
    <main>
      {mode === 'signin' ? <SignInForm /> : <SignUpForm />}
      <button onClick={() => setMode(mode === 'signin' ? 'signup' : 'signin')}>
        {mode === 'signin' ? 'Need an account? Sign up' : 'Have an account? Sign in'}
      </button>
    </main>
  )
}

Submitting the sign-in form updates the store, so the dashboard renders with no navigation code. Signing out clears the store, and the forms come back.

The dashboard

The signed-in view shows the user, their verification status, and calls the protected /api/profile route we wrote in Go. Create src/Dashboard.tsx:

import { useState } from 'react'
import { auth } from './auth-client'

type User = { id: string; email: string; emailVerifiedAt: string | null }

export function Dashboard({ user }: { user: User }) {
  const [resend, setResend] = useState<'idle' | 'sent' | 'failed'>('idle')
  const [profile, setProfile] = useState<string | null>(null)

  async function resendVerification() {
    try {
      await auth.requestEmailVerification()
      setResend('sent')
    } catch {
      setResend('failed')
    }
  }

  async function loadProfile() {
    // Your own API routes: plain fetch, cookie included.
    const res = await fetch('http://localhost:8080/api/profile', { credentials: 'include' })
    setProfile(JSON.stringify(await res.json(), null, 2))
  }

  return (
    <main>
      <h1>Signed in as {user.email}</h1>

      {user.emailVerifiedAt ? (
        <p>Email verified ✓</p>
      ) : (
        <p>
          Email not verified.{' '}
          {resend === 'sent' ? (
            'Check your inbox.'
          ) : (
            <button onClick={resendVerification}>Resend verification email</button>
          )}
          {resend === 'failed' && ' Sending failed, try again.'}
        </p>
      )}

      <button onClick={loadProfile}>Load profile from the Go API</button>
      {profile && <pre>{profile}</pre>}
      <button onClick={() => auth.signout()}>Sign out</button>
    </main>
  )
}

auth.signout() ends the session on the server and clears the store, so the useSession() guard in App flips back to the forms automatically. For your own endpoints, a plain fetch with credentials: 'include' carries the session cookie, and auth.GetSession on the Go side validates it.

Email verification

The verification email (for now, the server log line) links to /verify-email?token=... on the frontend. That page hands the token back to the server. Create src/VerifyEmail.tsx:

import { useEffect, useRef, useState } from 'react'
import { auth } from './auth-client'

export function VerifyEmail() {
  const [status, setStatus] = useState<'verifying' | 'verified' | 'error'>('verifying')
  const ran = useRef(false)

  useEffect(() => {
    if (ran.current) return // guard against double-run in React strict mode
    ran.current = true

    const token = new URLSearchParams(window.location.search).get('token')
    if (!token) {
      setStatus('error')
      return
    }
    auth
      .verifyEmail({ token })
      .then(() => setStatus('verified'))
      .catch(() => setStatus('error'))
  }, [])

  if (status === 'verifying') return <p>Verifying…</p>
  if (status === 'error') return <p>This verification link is invalid or has expired.</p>
  return (
    <p>
      Email verified. <a href="/">Continue to the app</a>
    </p>
  )
}

On success the SDK refreshes the session, so emailVerifiedAt is populated when the user returns to the dashboard.

What you built

A complete email/password auth flow: users can sign up, sign in, verify their email, and reach protected routes on both ends, with production-grade password hashing, session handling, and endpoint protection baked in.

Where to go from here

The same setup extends to:

The full client reference lives in the Client SDK docs, and the source for both sides is on GitHub.

Originally published at limenauth.dev.

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.