Authgear Server: a self-hosted identity provider written in Go

The gap Authgear fills between a library and a hosted identity service

Most teams building consumer login face the same fork. A library such as a WebAuthn helper or a JWT middleware gives you primitives and leaves the flows, the account recovery, the session revocation and the support tooling to you. A hosted service gives you all of that, and in exchange your user records live in someone else's database under someone else's pricing. Authgear positions itself in the middle: it is an identity provider you can run yourself, and it also sells a cloud version. The README calls it an "open-source extensible turnkey solution for all of your consumer authentication needs" and lists the intended audience as SaaS products and multi-app ecosystems.

The feature list is the argument. Passwordless login over email, SMS or WhatsApp. Passkeys and FIDO2 hardware keys. TOTP through Google Authenticator or Authy. SMS and email OTP as a second factor. Social connections to Google, Facebook, Apple, WeChat and LinkedIn. SAML enterprise SSO, plus ADFS and LDAP for B2B connections. A pre-built signup and login page, a pre-built account settings page, and a portal for support staff to manage users and revoke sessions. The README also mentions biometric login on iOS and Android, which is a client-side concern that the SDKs handle rather than the server.

That breadth is the point. If you need three of those things, a smaller library will cost you less to operate. If you need eight of them and a support team that can look up a locked-out user without writing SQL, the calculus changes.

What the repository actually contains: Go services, a GraphQL Admin API and a portal

The primary language is Go, and the default branch is main. The README names three surfaces that matter for anyone evaluating the architecture. First, the Authgear Portal, described as a web interface for user management and for configuring authentication and authorization. Second, the Admin API, described as a GraphQL API to manage resources and authentication. Third, the end-user facing flows: pre-built, tailorable screens that the README says support dark and light modes.

That split tells you where the boundaries are. Configuration is not a config file you edit and reload in isolation. It is data held by the server and manipulated through the portal or the Admin API. The login pages are served by Authgear rather than rendered by your application, which is why the README can promise a working signup flow without front-end work. Your app participates through the standard protocols it lists: OIDC, OAuth 2.0 and SAML.

For extension, the README points to webhooks and TypeScript hooks, described as a way to "get notified when important events such as new user signup happen" and to add custom logic. That is the escape hatch when a built-in flow does not match your product, and it is worth checking the hook documentation before you assume a behaviour can be changed, because a hook that fires after an event is not the same as a hook that can veto it.

One thing the README does not do is describe the deployment topology: how many processes, which datastore, what queues. That information lives in the docs site rather than the repository front page, and it is the first thing to read if you are planning to self-host.

Getting it running depends on documentation the README does not include

This is where the repository front page is thin, and it is worth being blunt about it. The README promises a five-minute start via developer-friendly SDKs and a comprehensive portal, but it does not print a docker run command, a compose file, a Helm chart name, or a single environment variable. The links it does provide are the docs site, the cloud offering, a demo instance and a Discord server.

So the honest description of the getting-started path is: the commands are in docs.authgear.com, not here. A reader who wants to evaluate Authgear without reading the docs will not get past the README. That is a deliberate choice on the project's part, since the docs are versioned and the README is not, but it means I cannot give you a verified command line from the material I have, and I will not invent one.

What the README does establish about configuration is the shape of it: authentication and authorization requirements are set up through the portal, and the Admin API is the programmatic route to the same resources. If your team prefers infrastructure as code, the GraphQL Admin API is the surface you would drive from a script or a Terraform provider, and the portal is the surface you would use interactively. Note that the README does not mention a Terraform provider. Whether one exists is something to check in the docs.

The release cadence is visible, though. The three most recent releases are tagged 2026-09-09.0, 2026-08-26.0 and 2026-08-12.0, which is a fortnightly rhythm. That is a fast enough cadence that pinning a version and reading release notes before upgrading should be part of your plan, not an afterthought.

Where self-hosting Authgear gets expensive

The README lists the deployment options as self-hosted or Authgear Cloud, and it does not pretend the two are equivalent in effort. Running the server yourself means owning the database, the upgrades, the backup story and the availability of your own login. When login is down, everything behind it is down. That is a different risk profile from running a stateless API, and it is the main reason teams choose the cloud option even when an open source alternative exists.

The upgrade cost follows from the release cadence. A new tagged release roughly every two weeks means roughly twenty-six upgrade decisions a year. Some will be routine. Some will involve schema migrations or configuration changes that the release notes describe. You need a staging environment where you can run the new version against a copy of production data before you touch production, and you need to read the notes for every release you skip.

The feature list also implies ongoing third-party dependencies you may not think about at evaluation time. SMS and WhatsApp delivery for passwordless login require a provider account and a per-message cost. Email OTP requires a mail path that does not land in spam. Social connections require you to register applications with Google, Apple, Facebook, WeChat and LinkedIn individually, and each of those has its own review process and its own breaking changes. Authgear removes the code you would write, not the vendor relationships.

On licensing: the repository is Apache-2.0, which is a permissive licence that generally allows commercial use and modification. That is a statement about the licence identifier, not legal advice. If you plan to redistribute a modified version, or to embed the server in a product you sell, have counsel read the actual licence text and any notices the project ships.

When Authgear is the wrong tool

The clearest mismatch is a single internal application with a handful of users. Authgear's value comes from the pre-built flows, the portal and the protocol breadth. If your users are employees on a corporate network and you already have an identity provider, adding a second one creates a synchronization problem you did not have before. The README's own framing points at consumer authentication for SaaS and multi-app ecosystems, and that framing is a useful filter.

A second mismatch is a product that needs a login experience the pre-built pages cannot express. Authgear serves the signup and login pages itself. That is a feature when you want to ship quickly and a constraint when your marketing site and your login page must be one continuous, heavily art-directed experience. The README says the flows are "tailorable", but tailoring within a framework is not the same as writing the page yourself. Check how far the customization goes before you commit to it.

A third case is a team with no appetite for operating stateful infrastructure. If nobody wants to own database backups, migration windows and on-call for the login path, the self-hosted route is a poor fit regardless of how good the software is. The cloud option exists for exactly this reason, and choosing it is not a failure of conviction about open source.

Finally, adaptive MFA is marked "coming soon" in the README. If your threat model requires risk-based step-up authentication today, that capability is not described as available, and you should plan around its absence rather than assume it.

How Authgear differs from Keycloak and from hosted identity services

The topics list on the repository puts Authgear next to Keycloak, Auth0, Clerk, Firebase Auth and SuperTokens, which is a fair map of the space. The most useful comparison for a self-hosting team is Keycloak, because both are open source identity providers you run yourself, and the difference is in emphasis rather than protocol support. Keycloak grew out of enterprise Java middleware and its centre of gravity is the admin console, realms and adapters for existing enterprise systems. Authgear's centre of gravity, judging by the README, is the consumer-facing surface: pre-built signup and login pages, pre-built account settings, passkeys and biometric login on mobile, and passwordless delivery over WhatsApp as well as SMS and email.

That shows up in the extension model too. Keycloak's customization story leans on Java service provider interfaces and themes. Authgear offers webhooks and TypeScript hooks, which is a lower barrier for a JavaScript-heavy product team and a dead end for anyone who wants to patch behaviour deep inside the server.

Against hosted services such as Auth0, Clerk and Firebase Auth, the difference is not features but ownership. You keep the user records and you keep the operational burden. The README's adopters section lists large enterprises, which is evidence that the self-hosted path is used in production by organizations with compliance requirements, though the README gives no detail on how those deployments are sized or operated. Do not read a logo wall as a statement about your own workload.

Who should adopt it, and what to verify first

Adopt Authgear if you are building consumer login for a SaaS product or a multi-app ecosystem, you need several of passkeys, passwordless, MFA, social login and SAML enterprise SSO in the same system, and you either want to run it yourself under Apache-2.0 or to pay for the hosted version instead. The combination of a pre-built account settings page and a support portal is genuinely hard to assemble from smaller parts, and it is the part of the product that saves the most engineering time.

Do not adopt it if you need one OAuth2 provider for an internal tool, if your login page must be fully bespoke, or if no one on the team will own a stateful service with a database and a fortnightly release train.

Before you commit, verify three things against the documentation rather than the README. First, the actual installation path: what image or binary the 2026-09-09.0 tag corresponds to, and which environment variables the server reads. Second, the depth of the TypeScript hooks, specifically whether a hook can block an authentication attempt or only observe it. Third, the upgrade procedure between releases, including what happens to existing sessions and user records when the schema changes. Those three answers determine whether self-hosting is a weekend or a quarter.

Editorial conclusion

Adopt Authgear if you want OIDC, SAML, passkeys and MFA behind one configuration surface and you are willing to run a Go service plus its database, or to pay for Authgear Cloud instead. Do not adopt it if you only need a single OAuth2 provider for one internal app, because the portal, Admin API and pre-built flows are weight you will not use. Before committing, verify how the release tags map to images or binaries, read the self-hosting section of docs.authgear.com for the exact environment variables your deployment needs, and decide whether your team wants to own database migrations and upgrades on a roughly two-week release cadence.

Official sources

1. authgear/authgear-server on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases