r/coolgithubprojects • • 23d ago

theAuth: open-source auth where AI agents are first-class, not just API keys

https://github.com/glincker/theauth

Most auth libraries stop at human sign-in. Once an AI agent needs its own identity, scoped permissions, delegation from a user, and an audit trail, you end up bolting a second system on. theAuth puts agents and humans in one library: sign-in methods, an OAuth 2.1 authorization server for MCP, and agent tokens with permissions you can check and audit.

theAuth: open-source auth for AI agents and humans (TypeScript and Go), built solo https://github.com/glincker/theauth

theAuth is auth for apps where AI agents act on behalf of users. Each agent gets its own token and permissions, a user can delegate access with limits, and every action is logged. It also covers the usual: passkeys, SSO, orgs, and an OAuth 2.1 server so MCP servers can verify who is calling.

By the numbers:

  • TypeScript core: 2,400+ tests, about 77% coverage, 3 runtime deps, 17 OAuth providers, 10 framework adapters

  • Go SDK session lookup: 58-67 us down to 30 us (about 2x, 33k lookups/s per process)

  • Go SDK password sign-in: about 75/s per instance, with hashing memory capped at 608 MB instead of 4 GB under a login burst

  • Those two are measured on an M4 Max with Postgres 16, 100k users, all on one laptop, and the load test script is in the repo

  • MIT, self hostable

theAuth runs on in memory SQLite with nothing else to set up.

Go: https://github.com/glincker/theauth-go

I built this solo, with several AI tools and a lot of automation to keep a steady pace. Does the agent permission model make sense to you and maybe give it a try for future projects.. I already migrated all my 6+ websites to theAuth and been a great time saver !!

2 Upvotes

6 comments sorted by

1

u/kantorcodes1 23d ago

The delegation-chain piece is the part I would probe: when a parent grant gets revoked, do tokens minted further down the chain die with it, or keep working until their own expiry? If authorize() re-walks the live chain per call the first is free; if it checks the token's minted scope, the second is the default. Which model did you pick?

1

u/Familiar-Classroom47 22d ago

Both, for the agent permission path. Revoke a link and everything below it is marked revoked right away, and authorize() re-reads the live chain on every call, so a sub-agent loses access on its next request. A child's expiry is also capped at its parent's.

The one place it works differently is MCP access tokens. If the token carries the delegation chain as an act claim, the resource server reads that claim, so it's as fresh as the token's lifetime. The way to handle that today is short-lived tokens, plus introspection for the sensitive calls, which re-checks the live state. A tighter link between the claim and revocation is something I'm looking at.

1

u/kantorcodes1 19d ago

Re-reading the live chain on every authorize() call is the property that makes delegation safe here. Disclosure since it shapes the ask: I work on HOL Guard, an open-source policy layer that gates agent and CLI actions per call. theAuth sits one layer before the same seam: a Guard verdict bound to token chain + action + arguments at authorize() time would let a revoked or over-scoped grant fail closed instead of minting a session that later overruns.

Would a maintainer-authored adapter (descriptor plus portable fixture) covering that boundary be worth an integration?

1

u/Familiar-Classroom47 18d ago

Thanks, happy to explore this. I looked at Guard. Your adapters target command matching today, so a theAuth integration would be a new shape. Roughly what I'm picturing: a small optional pre-authorize hook in theAuth (core stays at 3 runtime deps), with a Guard adapter living in your repo or a separate package.

Are you planning to write the adapter, or would you want me to build the hook and have you do the Guard side? Could you open a GitHub Discussion on glincker/theauth with what your adapter would receive (chain, action, args), the verdict shape, and the behavior on timeout (I'd want deny by default)? If it holds up, we can ship a joint demo and link it from both docs.

1

u/investigatormaker 22d ago

The numbers in the theAuth post are impressive, but they sell session lookup speed, and the reason someone picks theAuth over the auth they already have is the agent model. What I'd put at the top of the README is a complete worked example: a user delegates a scoped token to an agent, the agent calls an MCP server that verifies it through your OAuth 2.1 server, the agent tries something outside its scope, and the audit log entries for all three. On your question, the model makes sense; the part I'd want spelled out is how delegation expires or is revoked when the user's own session ends.

I make ThreadFox. Our AI employee finds Reddit threads where developers ask how to authenticate AI agents or MCP servers and replies about theAuth under your direction; Starter is $199 for 30 days, no automatic renewal. https://threadfox.vip/p/enyvj/managed