Authgear

Authgear is an open-source identity and access management (IAM) platform designed as a drop-in alternative to Auth0, Clerk, and Firebase Auth. It provides a complete, self-hostable authentication service that developers can deploy on their own infrastructure or use via Authgear Cloud, without vendor lock-in or per-MAU pricing surprises.

The platform ships with pre-built, fully customizable AuthUI pages for login, signup, and account settings — so teams avoid building auth screens from scratch. It supports every major modern authentication method: passkeys (FIDO2/WebAuthn), biometric login on iOS and Android, magic links, OTP via Email/SMS/WhatsApp, TOTP, and social logins through Google, Apple, Facebook, WeChat, LinkedIn, ADFS, and LDAP.

Authgear is built in Go with a modular server architecture. Its GraphQL-based Admin API provides programmatic control over users, sessions, roles, and policies. The included web Portal gives ops and support teams a GUI for user management, audit logs, session revocation, and authentication policy configuration. Extensibility is handled through TypeScript hooks (running on a Deno runtime) and webhooks, letting teams inject custom logic at key points in the auth flow.

The project has a strong enterprise pedigree, with production deployments at organizations like Bupa, MTR, and K11. It ships with rate limiting, bot protection, brute-force lockout, IP blocklists, RBAC via roles and groups, and SAML 2.0 enterprise SSO — giving compliance-focused teams the controls they need without piecing together multiple services.

What You Get

• Passkeys and FIDO2 WebAuthn - Native support for hardware security keys and platform authenticators (Face ID, Touch ID, Windows Hello), letting users log in without passwords using phishing-resistant credentials.
• Biometric Login on iOS and Android - Native SDK integration with device biometrics so mobile apps can authenticate users with a fingerprint or face scan, reducing friction at onboarding and re-authentication.
• Multi-Factor Authentication (MFA) - Built-in TOTP (Google Authenticator, Authy), SMS OTP, Email OTP, and WhatsApp OTP as additional authentication factors, configurable per-app without writing auth logic.
• Pre-built AuthUI - Fully customizable login, signup, and account settings pages that render out of the box with dark/light mode, responsive design, and i18n support — no frontend auth screens to build.
• GraphQL Admin API - Programmatic access to all user management operations — creating, blocking, deleting users, managing roles and groups, revoking sessions, and querying audit logs — with auto-generated TypeScript client types.
• SAML 2.0 and OAuth2/OIDC SSO - Enterprise SSO support for ADFS, LDAP, Azure AD, Google Workspace, and any SAML or OIDC-compliant provider, enabling B2B use cases where clients authenticate via their own IdP.
• TypeScript Hooks via Deno - Server-side TypeScript functions that execute synchronously or asynchronously on auth events (user created, login blocked, token pre-issue), enabling custom business logic without forking the server.
• Role-Based Access Control (RBAC) - Fine-grained roles and groups that can be embedded into JWT tokens, allowing downstream services to enforce permissions without additional API calls.
• Web Portal for User Management - GUI for managing users, revoking active sessions, viewing login attempts and audit logs, configuring MFA policies, blocking accounts, and setting up authentication flows.
• Bot Protection and Rate Limiting - Built-in brute-force lockout, IP blocklists, disposable email domain blocking, and configurable rate limits to protect auth endpoints from abuse without a third-party WAF.

Common Use Cases

• Multi-tenant B2B SaaS with SAML SSO - A B2B SaaS company deploys Authgear to handle authentication for multiple enterprise clients, each using their own SAML or OIDC identity provider, with separate branded login pages and RBAC policies per tenant.
• Mobile app with passwordless biometric login - A fintech startup integrates the Authgear iOS and Android SDKs to enable biometric authentication and passkeys, eliminating password reset flows and reducing account takeover risk.
• Centralized auth for a microservices platform - An e-commerce platform runs Authgear as its sole identity service, issuing JWT tokens with embedded roles that 20+ downstream microservices validate independently without additional round-trips.
• Healthcare portal with compliance requirements - A healthcare provider self-hosts Authgear to meet data residency and audit requirements, using MFA enforcement, audit logs, account lockout policies, and SAML SSO for clinical staff access.
• Consumer app with social login and OTP - A retail app uses Authgear to let customers log in with Google, Apple, or a WhatsApp OTP, with a pre-built account settings page for profile management and 2FA enrollment.
• Developer platform with Admin API automation - An infrastructure team uses the GraphQL Admin API to automate user provisioning and deprovisioning, syncing accounts from their HR system to all internal tools via a single integration point.

Under The Hood

Architecture Authgear is structured as a modular monolith where distinct domains — authentication flows, the admin API, the portal, OAuth/OIDC, SAML, and background job processing — are separated into isolated packages with their own dependency graphs. Dependency injection is handled by Google Wire, which generates provider sets at compile time, enforcing clean composition without runtime reflection. The authentication flow engine uses a declarative graph model: flows are defined as a tree of intents and nodes, and the engine traverses and resolves them step-by-step, making complex multi-factor and branching flows composable without conditional spaghetti. Separate entry points for the main server, portal, background worker, and image server allow independent scaling while sharing the same core libraries. OpenTelemetry tracing, metrics, and structured logging are injected as middleware at the request boundary, giving operators full observability without instrumentation scattered through business logic.

Tech Stack The backend is written in Go 1.26 using a compile-time dependency injection approach via Wire. PostgreSQL serves as the primary data store for user records, sessions, and audit logs, accessed with Squirrel as a SQL builder rather than a full ORM. Redis handles session caching, distributed rate limiting, and background task queues via a custom redisqueue package. TypeScript hooks run inside a Deno subprocess, isolated from the main server process, communicating over a local HTTP boundary. The AuthUI frontend is a TypeScript/Vite application with Tailwind CSS, while the Portal is a TypeScript/React SPA that talks to Authgear’s own GraphQL Admin API. Deployment tooling includes Helm charts for Kubernetes, Docker Compose for local development with MinIO, pgBouncer, nginx, and a full Grafana/Loki/Tempo/Prometheus observability stack.

Code Quality The codebase has 434 unit test files in the core packages, and a dedicated e2e test runner that executes scenario-based YAML test cases against a full running stack. Error handling is explicit and structured throughout — errors are typed, HTTP-status-aligned, and propagated without swallowing. The project uses gomock for interface mocking, goconvey for BDD-style test assertions, and has comprehensive linting integrated into its Makefile-driven CI. Wire-generated DI code is checked into the repo and verified during CI, preventing wiring mismatches from slipping into builds. Code organization is disciplined: domain logic lives in pkg/lib, API entrypoints in pkg/api, and HTTP handlers in pkg/resolver, keeping layers from collapsing into one another.

What Makes It Unique The most distinctive technical choice is the declarative authentication flow engine: flows are described as intent graphs with typed node transitions, which means adding a new authentication step (like adding a fraud-check node before OTP) is a matter of composing a new node type rather than modifying existing state machines. The TypeScript hook system using Deno is another standout — it lets teams write real TypeScript that executes server-side at critical auth events, a capability that Auth0 calls “Actions” but here is fully self-hostable. The Authgear Once variant (in the once/ directory) bundles the entire platform into a single binary for teams that want to self-host without Kubernetes, lowering the operational floor significantly. The combination of passkeys, SAML, LDAP, biometric SDKs, WhatsApp OTP, and custom TypeScript hooks in a single Apache-licensed package is genuinely hard to match with alternatives.

Self-Hosting

Authgear is released under the Apache License 2.0, one of the most permissive open-source licenses available. This means you can use it commercially, modify the source code, distribute your modifications, and integrate it into proprietary products without any copyleft obligation — you are not required to open-source your own application because you use Authgear. The only requirement is that you include the original copyright notice and license text. There are no usage restrictions based on number of users, applications, or organizations.

Running Authgear yourself requires meaningful infrastructure investment. The recommended production deployment path uses a Helm chart on Kubernetes, backed by PostgreSQL (with pgBouncer for connection pooling), Redis, and object storage (MinIO or S3-compatible) for user-uploaded images. The full observability stack — Grafana, Loki, Tempo, and Prometheus — is provided as Docker Compose configuration for reference. There is also Authgear Once, a single-binary distribution designed for simpler self-hosted deployments without Kubernetes. TypeScript hooks require a running Deno runtime as a sidecar process. You are fully responsible for uptime, database backups, Redis persistence, certificate management, and upgrades — each release ships as a new Docker image tag and the upgrade path requires running database migrations before deploying the new image.

The Authgear Cloud SaaS offering provides managed hosting with automatic upgrades, built-in HA, support SLAs, and a free tier to get started quickly. Self-hosting gives you complete data residency control and eliminates per-MAU pricing — the primary reason teams choose self-hosting for compliance-sensitive verticals like healthcare or finance. What you trade away is the operational burden of maintaining the stack, access to premium support tiers, and potentially some cloud-exclusive features (like advanced analytics integrations) that the SaaS team ships before open-source parity. The project is actively maintained with releases roughly every 4-6 weeks, so the gap between cloud and self-hosted feature sets is generally small.