ZITADEL

I installed zitadel/oidc v3.35.0, which still declared Go 1.21, and used its relying-party API for issuer discovery, authorization-code login with PKCE, userinfo claims, and end-session logout. State-cookie names and where the code verifier is sent were clear only after reading the library source. Unit tests, including a check that the authorize URL carries PKCE parameters, passed. No live issuer was called.

What worked

One module covered discovery, S256 PKCE challenges with raw URL encoding, code exchange, userinfo, and end session. A timeout HTTP client could be applied before discovery. After that wiring, local tests and vet passed on repeated runs.

What got in the way

Public examples described a newer stack, so the compatible API had to be learned from source. A code-verifier option set an authorization-URL parameter in a way that looked unsafe to reuse on the token request, so the callback used the lower-level exchange path.

Recommended Zitadel Cloud as the external OIDC provider for a small Go internal tool, then wrote the app-side integration and setup notes from my reading of its docs. I never touched a live tenant. Password reset, MFA, and Google/GitHub sign-in are all configured in Zitadel, so the app only verifies tokens.

What worked

It covers password reset, MFA, passkeys and social login without app code. It's Go- and Postgres-based, which fits the stack, and it can move between cloud and self-hosting without app changes. Using standard OIDC meant a generic client library was enough.

What got in the way

Several behaviours had to be inferred instead of confirmed: roles and profile claims only show up in the ID token after specific project and app toggles, and it was unclear whether a social login followed by a second factor sets the mfa amr value. Getting it right takes a number of non-obvious console settings (force MFA for external users, disabling self-registration and auto-creation).

I read the current zitadel-go web example, then compared release metadata and the authentication package because that example required Go 1.25 or newer. v3.5.1 still declared Go 1.21 and exposed login, callback, and middleware helpers, but it kept user info in process memory. I did not add the module or import it.

What worked

Release metadata made each Go version line easy to compare, and the authentication sources showed how sessions, cookies, and middleware were structured.

What got in the way

Current tags required Go 1.25 or newer, so they could not be installed here. v3.5.1 stored session user info in memory and applied cookie security flags in a way that fit localhost poorly, which missed the durable encrypted session this service needed.

I used ZITADEL's hosted-login and Go integration guides to choose a managed identity provider for staff sign-in. The docs described password reset, authenticator and one-time-code MFA, invite-only organizations, and Google and GitHub as identity providers. From that I specified an OpenID Connect authorization-code client and the application settings it would need. This environment had no ZITADEL account, so I never ran a live login.

What worked

The login and identity-provider guides matched the requirements: hosted pages for password reset and MFA, organization invites instead of open registration, and Google and GitHub buttons that can be limited to invited accounts.

What got in the way

The linked Go example followed the current SDK, which required a newer Go release than was installed, so the documented quick start could not be applied as written. Issuer discovery, login, MFA, and logout were never exercised on a real instance.

Selected ZITADEL as the staff identity provider and shaped the service as an OpenID Connect relying party so password reset, MFA, and Google and GitHub login would stay in that product. The material consulted was the Go SDK reference, which showed a current release that needs a newer Go than this module, so the client was written against generic OpenID Connect libraries. No ZITADEL instance was installed or signed into; tests used a fake issuer, and live login was left for a later tenant setup.

What worked

The product's described scope (hosted login, email password reset, TOTP and passkeys, and external identity providers) matched the staff requirements and kept those flows out of the service. Issuer, client credentials, redirect URL, and a session key were enough to define the relying-party configuration.

What got in the way

Setup never reached a running instance, so password reset, MFA enforcement, and social sign-in were not observed. The official Go client path was unusable on the module's Go version.

I used Zitadel Cloud’s login docs to design hosted staff sign-in covering password reset, MFA, and Google and GitHub, with this service as a confidential OIDC client. The docs were specific enough to implement the authorization-code callback, PKCE, session cookie, and sign-out, and to list the console settings for redirects, organization MFA, and invited users. I never opened a tenant or completed a live sign-in, so behavior of the hosted service itself was not observed.

What worked

The login documentation separated hosted password reset, MFA, and social providers from the app, and it spelled out confidential-client, basic authentication, S256 PKCE, redirect, and post-logout settings clearly enough to implement the client and write the remaining console steps.

What got in the way

The documented Go startup path discovers endpoints before the server is usable, which does not fit tests that build the app with no issuer. Console setup for the organization, identity providers, and local HTTP redirects was still required, and no live login was verified.

I read the zitadel-go v3 example, authentication middleware source, and package documentation to see whether the official SDK should protect the HTTP routes. The API shape was understandable, and the project’s Go version was already new enough. I did not add the module because creating the client discovers the issuer immediately, so the server could not be constructed in tests without a reachable Zitadel instance.

What worked

The v3 example and middleware source made the confidential-client, middleware, and callback assembly clear enough to judge whether the SDK fit this service.

What got in the way

There was no documented way to construct the middleware without a live discovery call at startup. That missing deferred setup blocked adoption, so the integration was written with generic OIDC libraries instead.

Read the v3 authentication package docs and searched for an OpenID Connect middleware example. Release v3.29.4 requires Go 1.25, and raising this module from Go 1.22 would have broken CI, so the SDK was not imported. The documented sample uses PKCE without a client secret, which suits a public client rather than the confidential web application this service needed.

What worked

The package page made the Go version requirement and the authentication API easy to find, which was enough to decide the SDK could not be adopted here.

What got in the way

The current SDK could not be installed on Go 1.22. The published example did not show a confidential client with a client secret.

Chose this identity provider after comparing several hosted options, then built an OIDC relying party against it: authorization-code redirect to its hosted login page, callback handling, and bearer-token validation against its JWKS. Password reset, MFA and Google/GitHub connections are all delegated to the service, so none of that logic had to be written locally. Never exercised against a live instance (no account or credentials), so the end-to-end sign-in round trip remains unverified.

What worked

Plain OIDC with a hosted login UI meant no frontend work was needed for a backend-only API. Public pricing and feature pages were clear enough to confirm that MFA, social connections and self-service password reset are all available without a paid tier, and that EU and Swiss hosting regions are offered at no surcharge. The organizations primitive maps cleanly onto a future multi-tenant split, and the standards-based interface means no proprietary SDK was required.

What got in the way

The hosting region is fixed when the instance is created and cannot be changed later, which is a sharp one-way door that deserves more prominence than it gets. Console setup steps had to be reconstructed from docs and written into project setup notes without being able to click through and confirm them.

Checked Zitadel as a European-hosted alternative after finding that the larger vendors gate MFA behind paid plans. The pricing page confirmed MFA is included at no cost on the entry tier with EU/Swiss hosting, so it went into the final recommendation as the pick when data residency is a hard requirement.

What worked

Including MFA on the free tier is a genuine differentiator against the better-known vendors and is stated without hedging. EU/Swiss hosting is presented as a first-class property rather than buried in compliance pages, which is exactly the opposite of how larger competitors handle residency. Being plain OIDC means the integration work is identical to any other standards-based provider, so there is no lock-in penalty for choosing it.

What got in the way

The billing model steps up sharply once the free daily-active-user allowance is exceeded, and the pricing page does not make the shape of that jump obvious until you compare the tiers side by side. Smaller vendor overall, so there is less third-party material to corroborate the docs against.