Tinyauth is a small Go authentication and authorization server that runs either as authentication middleware in front of self-hosted applications or as a standalone authentication server, and it is aimed at self-hosters and homelab operators who want OpenID Certified™ single sign-on without deploying a large identity platform.

What it is

Tinyauth sits in the Security & Privacy / Identity & Access Management (IAM) category and is written in Go under the AGPL-3.0 licence. Its own description is "The tiniest OpenID Certified™ authorization and authentication server you have ever seen." It is designed to work two ways at once: as an authentication middleware for existing applications, with support for OAuth, LDAP and access controls, and as a standalone authentication server. It integrates with the popular reverse proxies Traefik, Nginx and Caddy. As of 2026-06-25, Tinyauth v5.1.0 is OpenID Certified™ for Basic OP, with the certification details and the public test suite linked from the project.

The problem it solves is the authentication layer that otherwise has to be built or bolted on for every proxied service. Rather than giving each self-hosted application its own login implementation, an operator places Tinyauth in the request path, where it handles authentication and access control for the applications behind it. That keeps credential handling in one component and lets OAuth and LDAP identities feed the same gate. The project also ships a demo instance and a documented configuration surface, so a deployment can be evaluated before it is wired into a live proxy.

Key capabilities

• Runs as authentication middleware for existing apps and as a standalone authentication server from the same project.
• Supports OAuth and LDAP as identity sources, alongside built-in access controls.
• Integrates with Traefik, Nginx and Caddy as the fronting reverse proxies.
• Holds OpenID Certified™ status for Basic OP as of Tinyauth v5.1.0, dated 2026-06-25, with a public certification plan.
• Provides two-factor authentication via TOTP, reflected in the project topics for 2fa and totp.
• Ships a docker-compose.example.yml containing Traefik, Whoami and Tinyauth to demonstrate the full flow.
• Offers a hosted demo at demo.tinyauth.app with default credentials user and password.

Who uses it and how

• Self-hosters and homelab operators, the audience the project's Discord explicitly names for discussion of self-hosting and homelabs.
• Operators running Traefik, Nginx or Caddy who need a single authentication and authorization gate in front of several applications.
• Teams that already hold identities in OAuth or LDAP sources and want those identities reused for access control rather than duplicated per service.
• Prospective adopters evaluating fit against the hosted demo before installing anything.
• Contributors and translators, who work through the contributing guide and the Crowdin translation project.

Getting started

Start with the getting-started guide at tinyauth.app/docs/getting-started, or run the bundled docker-compose.example.yml, which brings up Traefik, Whoami and Tinyauth together. Note that this compose file lives on the main development branch and may contain changes that are not yet released.

How it compares

No comparable authentication servers are named in the facts for this entry, so Tinyauth stands alone in this registry on that axis. The proxy names it lists, Traefik, Nginx and Caddy, are integrations it authenticates behind rather than alternatives it competes with.

When to use it — and when not to

Choose Tinyauth when a compact authentication and authorization layer is wanted in front of proxied self-hosted applications, and when the operator accepts reading release notes before each update: the project states it is in active development and that configuration may change often. Anyone who needs a frozen, unchanging configuration surface, or who cannot meet the AGPL-3.0 requirement to publish source for a modified version run over a network, should look elsewhere. The example compose file and the main development branch should also be treated as moving targets rather than pinned deployment references.