Go auth libraries: pick by the side of the wire you are on

Which side of the wire are you on? Are you calling someone else's API, checking a token someone else issued, or issuing tokens yourself? Go auth libraries cluster by that answer, and OAuth threads go wrong when people skip it. This article sorts the main libraries into four groups and ends with a decision flow you can follow in a minute.

I maintain theauth-go, a four month old library with 6 GitHub stars, so weigh my opinions accordingly. The article is not really about it.

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

Which Go auth library should I use?

Someone asks "which auth library should I use" and gets answers that solve three different problems. Name your side first, then the shortlist gets short.

Stats are from the GitHub API on 2026-10-30.

Side of the wire	You are...	Look at	Stars
Client	Calling an API with OAuth credentials	golang/oauth2, grokify/goauth	5,908 and 74
Verifier	Checking tokens or ID tokens from a provider	coreos/go-oidc	2,503
Embeddable server	Issuing tokens or signing in users inside your own process	fosite, theauth-go, others	2,631 and 6
Standalone server	Running identity as a separate service	Hydra, Dex, Zitadel	17,639, 11,227, 15,484

Which Go library calls an OAuth API for me?

If your Go program needs a token to call GitHub, Google or a SaaS API, you are a client. The anchor is golang/oauth2 (pkg.go.dev docs). Its README calls it a client implementation of the OAuth 2.0 spec, defined in RFC 6749. The repo has 5,908 stars, dates from 2014-04, was last pushed 2026-09-08 and uses a BSD-3 license.

On top of that sits a layer of convenience. grokify/goauth is the one I want to say something kind about. The project is small (74 stars, from 2017-06, last pushed 2026-10-30, MIT) and does real work. Its README describes a way to create authenticated *http.Client instances from a single JSON configuration file, with pre-configured endpoints for 40+ OAuth 2.0 providers. It lists six grant types, PKCE (RFC 7636) and DPoP (RFC 9449) support, and command line tools for token generation.

That shape helps if you juggle credentials for a dozen SaaS APIs in one program and want one config format. Its last push was the day of my snapshot. If your problem is "I call twelve vendor APIs", look at goauth before you write your own token plumbing.

None of this is a server. These libraries exist so your program can get and use tokens, not issue them.

Note: sign-in with social providers sits on the border. Goth (markbates/goth, 6,620 stars) is a client side library for "Sign in with X" in a web app. It consumes other providers. It is not a server you run for others.

How do I verify OIDC ID tokens in Go?

If a provider issued the token and your service only needs to trust it, you are a verifier. The library is coreos/go-oidc (pkg.go.dev docs). Its README describes an OpenID Connect client that works with golang.org/x/oauth2. The quick start creates a provider by discovery, then an ID token verifier:

provider, err := oidc.NewProvider(ctx, "https://accounts.google.com")
// ...
idTokenVerifier := provider.Verifier(&oidc.Config{ClientID: clientID})

The README snippet is cut short here. The full version also builds the oauth2.Config. The repo has 2,503 stars, dates from 2015-06, was last pushed 2026-10-19 and uses Apache-2.0. Its README says over 1000 open source projects import it. The ID token format itself comes from the OpenID Connect Core spec.

Choose this when your service sits behind an identity provider (Google, Okta, a Kubernetes cluster) and the work is checking signatures, issuer and audience. You do not need an auth server for that. Adding one means extra moving parts for no gain.

Which Go library lets me run my own OAuth server?

Now you are the provider. Users sign in to you, or other apps ask you for tokens. Embeddable means the code runs in your binary, mounts on your router, and uses your database.

The long standing option for the protocol half is fosite (2,631 stars, from 2015-12, last push 2025-11-20, Apache-2.0). Its README describes an OAuth2 and OpenID Connect framework. Fosite is a toolkit, so storage and user handling are yours.

For web sign-in flows there is authboss (4,201 stars). For passkeys alone there is go-webauthn (1,357 stars).

Then there is theauth-go, which tries to put sign-in, an OAuth 2.1 server and MCP authorization behind one http.Handler. Here is the sign-in half, shortened from its README quick start (I left out the database setup, and the README 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())

The honest comparison: fosite has a decade of use and one focused job. Theauth-go has months of use and a wide job. If you only need the OAuth server half, read fosite's README first. If you want the pieces pre-assembled and can accept a young dependency, mine is worth a trial in a sandbox.

When should I run a standalone auth server?

Sometimes the right answer is not a library. You run a service, and your Go apps talk to it over HTTP. These stats come from the same 2026-10-30 snapshot. I copied the shape column from my own research notes and did not recheck it against each README.

Project	Stars	License	Shape
ory/hydra	17,639	Apache-2.0	OAuth2 and OIDC provider, separate service
dexidp/dex	11,227	Apache-2.0	OIDC federation
zitadel/zitadel	15,484	AGPL-3.0	Full identity platform

Pick this side when a mix of languages shares one identity system, when a team other than yours operates it, or when you want a project with that kind of adoption behind it. Zitadel is AGPL-3.0, which matters to some companies and not to others, so read it before you plan around it. Any standalone server is one more thing to deploy, upgrade and keep available.

A decision flow for choosing a Go auth library

Are you calling an API with your own credentials?
  yes -> client side: golang/oauth2, or grokify/goauth for multiple vendors
  no  -> continue

Did another party issue the token you need to check?
  yes -> verifier: coreos/go-oidc
  no  -> continue

Do you need to issue tokens or sign users in?
  yes -> Must it run as its own service, or serve a mix of languages?
           yes -> standalone server: Hydra, Dex, Zitadel
           no  -> embeddable: fosite (protocol only), authboss (web flows),
                  go-webauthn (passkeys only), or theauth-go (all in one, young)

Real systems hit more than one box. A service can verify tokens with go-oidc at the edge, call vendors through oauth2 behind it, and embed a server for its own users. Use the flow to pick a starting library per job, not one answer for the whole app.

Where the lines blur

Two places trip people up. First, goth and goauth both help with "Sign in with Google", but goth targets web app login while goauth centers on authenticated API clients. Check which one matches your flow.

Second, an embeddable server often includes a verifier. If you run your own authorization server and also host an API, your API still has to check tokens. In theauth-go that is a separate zero dependency module called mcpresource, so a resource server skips the whole library.

Frequently asked

Do I need an auth server to verify tokens from Google or Okta?

No. A provider already issued the token, so you are a verifier. go-oidc checks signature, issuer and audience, and you run no server of your own.

Which Go library is for calling several vendor APIs?

Start with golang/oauth2. If you juggle credentials for several providers, goauth offers one JSON config and pre-configured endpoints for 40+ OAuth 2.0 providers.

Is a library or a standalone server better?

It depends on who operates it. A standalone server suits mixed languages or a separate team. A library keeps everything in one binary, with fewer services to run.

The bottom line

Before you compare feature tables, name your side of the wire. Calling an API points you to oauth2 or goauth. Trusting a provider points you to go-oidc. Issuing tokens points you to fosite, authboss, go-webauthn, a standalone server, or an all in one like mine. Star counts tell you how many people have looked. They say nothing about fit, so read the README and run the example.

If your case falls between two of these boxes, which one and why? That is the part I want to hear about.

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

The right Go auth library is whichever one matches the side of the wire you actually stand on.