Five Go auth libraries I would look at in 2026

Disclosure first: I maintain theauth-go, one of the five Go auth libraries below. The project is about four months old and has 6 GitHub stars. The other four have years of history and far more stars. I'll give a snapshot of each, say which job it fits, and tell you plainly when another one is the better pick.

Repo: glincker/theauth-go (MIT licensed Go library). Docs: docs.theauth.dev/go.

"Go auth library" covers at least five different jobs, and most bad comparisons mix them. A social login helper and an OAuth 2.0 server SDK share little except the word auth. So I picked five libraries with five distinct shapes instead of ranking them. Treat this as a list to look at, not a verdict.

Which Go auth library fits which job? The short version

Stats come from the GitHub API, pulled on 2026-10-30. Stars move, so treat them as a snapshot.

Library	Stars	Created	Last push	License	What it is for
ory/fosite	2,631	2015-12	2025-11-20	Apache-2.0	Building an OAuth2 and OpenID Connect server, no user management
aarondl/authboss	4,201	2015-01	2026-07-10	MIT	Modular web sign-in, confirm and recover flows
markbates/goth	6,620	2014-10	2026-02-11	MIT	Social login against a list of providers (client side)
go-webauthn/webauthn	1,357	2021-12	2026-10-29	BSD-3	WebAuthn and passkeys only
glincker/theauth-go	6	2026-06	2026-10	MIT	Sign-in, an OAuth 2.1 server and MCP authorization in one library

1. When to use fosite: you need to be an OAuth2 server

The fosite README calls it a security first OAuth2 and OpenID Connect framework for Go, built on the IETF RFCs. The protocol machinery comes in the box. You supply the storage and the story about who your users are. The pkg.go.dev page has the API.

Pick fosite when your product issues tokens to other people's apps. It has a history back to 2015 and a README that names the RFCs it follows. For that job it is the more established choice.

Know the tradeoff. Fosite is a toolkit, so expect to write the glue: storage, consent screens, login. It won't hand you a sign-in page. Its last push in the snapshot was November 2025, which isn't stale for a protocol library, but check the issue tracker for the features you need.

2. When to use authboss: classic web sign-in

Authboss describes itself as a modular authentication system for the web. You enable the modules you need and leave out the rest. Its README table of contents covers use cases such as resetting a password, and it says the library should integrate with or without any web framework. Package docs are on pkg.go.dev.

Pick authboss for a server-rendered site where users sign up, confirm an email and recover a lost password. You get those flows written once by someone else. It has been around since 2015.

You will write its storage and user interfaces yourself. Its README lists CSRF protection and request throttling as things your app must bring. If you also need an OAuth server or passkeys, you will be bolting on other pieces.

3. When to use goth: users arrive from other providers

Goth is the oldest and most starred library here. Its README lists a long set of providers, including Google, GitHub, Apple, Okta and OpenID Connect with auto discovery. If yours is missing, you implement its Provider and Session interfaces.

Pick goth when the whole job is "Sign in with X" and you already have your own user table. It stays out of your storage and session design, which is a feature if you have opinions there.

Goth is client side by design. It talks to other providers. It does not make you one, and it does not manage passwords or MFA. The last push in the snapshot is February 2026, so test the provider you need before you commit.

4. When to use go-webauthn: passkeys are the job

The go-webauthn README says the library handles Web Authentication for Go apps that want multi-factor, passwordless or usernameless sign-in. It also says the library is conformance tested against the relevant tools. The protocol itself is specified in the W3C Web Authentication spec. The last push came the day before my snapshot.

Pick it when you already have an auth system and want to add passkeys properly. It does one thing, and that narrowness is the point. You wire the ceremonies into your own session handling.

If you wanted a full system, this is a building block. That is fine, as long as you know it going in.

5. When to use theauth-go: one embedded library

This one is mine, so read with that in mind. The theauth-go README describes a self-hosted, MIT licensed library that mounts into your own server as an http.Handler.

It covers sign-in for people: passwords, magic links, social login, passkeys, TOTP, SAML SSO and SCIM. It also covers sign-in for software: an OAuth 2.1 authorization server with PKCE (RFC 7636), DPoP (RFC 9449) and token exchange, plus a resource server module for MCP.

The code below shortens the README quick start. The real one also sets up the SQLite database and runs the migration before theauth.New, and it hard codes a localhost base URL where I read an environment variable.

a, err := theauth.New(theauth.Config{CoreStorage: store, BaseURL: os.Getenv("BASE_URL")})
if err != nil {
    log.Fatal(err)
}
defer a.Close()

mux := http.NewServeMux()
mux.Handle("/auth/", a.Handler()) // sign-up, sign-in, magic link, sessions
mux.Handle("GET /me", a.RequireAuth()(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    user, _ := theauth.UserFromContext(r.Context())
    w.Write([]byte("hello " + user.Email))
})))

Storage options are memory, SQLite, Postgres and MySQL, and feature support differs per backend. Releases carry cosign signatures, an SBOM and build provenance attestations (the README badge says SLSA 3). Levelrail, another project I maintain, imports it in production code.

Pick it if you want sign-in and an OAuth server in one module, or you need MCP authorization from Go. Otherwise, read the next section.

What theauth-go does not do

I would rather you hear this from me.

The library is young. The repo's first commit was in June 2026, and six stars suggests few people outside my own projects have run it. It has had far less outside use than libraries that date from 2014 and 2015.

I have no head to head benchmark against anyone, so I make no speed claims. The one performance number I trust is narrow. A session lookup as one joined query took 30 microseconds against 58 to 67 for two queries, on one Apple M4 Max, using BenchmarkSessionLookup. That compares two designs inside my own code and says nothing about other libraries.

It also doesn't replace a standalone identity server. Casdoor, Zitadel and Authelia run as separate servers. If you want that shape, you are shopping in a different aisle (the next article in this series maps it).

Finally, breadth has a cost. One library doing sign-in, OAuth server and SCIM means more surface for me to maintain than fosite's single job. If you need only one slice, the focused library is the safer pick. That means fosite for an OAuth server, go-webauthn for passkeys and goth for social login.

How do I choose between these Go auth libraries?

If your job is	Look at first
Issue OAuth2 or OIDC tokens, bring your own users	fosite
Email and password flows on a server rendered site	authboss
Only "Sign in with X"	goth
Add passkeys to an existing system	go-webauthn
Sign-in plus OAuth 2.1 plus MCP in one embedded module	theauth-go, with the age caveat above

Frequently asked

Which of these Go auth libraries handles passwords and email confirmation?

Authboss. It covers sign-up, email confirmation and password recovery for server-rendered sites. Goth and go-webauthn don't manage passwords.

Can I use fosite as a sign-in library?

No. Fosite issues tokens as an OAuth2 and OpenID Connect server and leaves users, storage and login screens to you.

Is theauth-go ready to replace the older libraries?

Not on age. For a single job like passkeys or social login, the focused library is the safer pick.

The bottom line

None of these is "the" Go auth library. The question hides five questions. Decide which side of the wire you are on, how much of the user lifecycle you want to own, and how much age you need in your dependency. Then read the README of the one that fits and try its example before you believe me or anyone else.

Which job was yours, and did one of these fit? I would like to hear where the gaps are.

If you want to read the code or try it, the repo is here:

glincker / theauth-go

Self-hosted Go authentication library. Embeds in net/http, chi, Gin, Echo or Fiber. OAuth 2.1 authorization server, MCP authorization (RFC 9728), passkeys, SAML, SCIM, TOTP, magic links, DPoP. SQLite, Postgres or MySQL. MIT, no hosted service.

theauth-go

OAuth 2.1 and sign-in for Go MCP servers and agents. It mounts into your own net/http server, your users and tokens stay in your own database, and there is no hosted service. MIT licensed.

Building an MCP server in Go means implementing OAuth 2.1, protected resource metadata (RFC 9728), PKCE and token validation yourself. This library does that part, so your server accepts tokens from MCP clients and you keep control of identity.

Checked against a real client. The official modelcontextprotocol/go-sdk client (v1.8.0) completes the full flow against it in integration/mcp-interop: discovery, dynamic client registration, PKCE S256, token exchange and an authenticated tool call. Login and consent are simulated in that test, so it proves the protocol path, not a production deployment.

Who it is for: Go developers building MCP servers, agent backends or internal tools who want to own their auth instead of renting it.

What you…

View on GitHub

---

GDS K S · thegdsks.com · building Glincker · follow on X @thegdsks

Picking an auth library means picking which job you refuse to write yourself.