> For the complete documentation index, see [llms.txt](https://docs.esignet.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.esignet.io/home/esignet-2.0.0/readme/migration-to-go.md). # Migration to Go ### Background eSignet was originally built on Java, and the platform's early growth, its adoption across implementations, and its maturity as a standards-compliant identity solution were all built on that foundation. As eSignet's role has expanded, however, so has the case for revisiting what runs underneath it. This page lays out why the eSignet team made the decision to migrate the platform's core authentication engine to Go, what approach was taken to get there, and what it means for the product going forward. It is a deliberate architectural decision, made for two concrete reasons: long-term sustainability through shared engineering ownership, and a meaningful gain in runtime performance. Both are explained below, along with the approach taken to realize them without disrupting anything the product already promises its users and adopters. ### The Case for Migration #### 1. Sustainability Through Shared Ownership Open-source infrastructure is only as durable as the community maintaining it. For most of its life, eSignet's core engine has been maintained by a single team. That's workable, but it isn't the most resilient model for a piece of infrastructure that governments and service providers are expected to depend on for years. The opportunity to move to Go emerged directly from this concern. [WSO2](https://wso2.com/), **an established identity and access management vendor**, had already built and was actively maintaining [Thunder ID](https://thunderid.dev/) (referred to elsewhere in these docs as the [ThunderID engine](https://github.com/thunder-id/thunderid)), a Go-based identity engine addressing much of the same problem space as eSignet. Rather than build a comparable engine from scratch and maintain it alone, eSignet's team chose to build on top of Thunder, adapting and extending it to meet the OpenID Connect and FAPI 2.0 compliance eSignet requires as a national-scale identity backend. This changes eSignet's maintenance model in a substantive way. The core engine now has two engineering teams with a direct stake in its correctness, security, and continued development, eSignet's own team and WSO2's. Improvements, hardening, and bug fixes made to Thunder for any reason benefit eSignet as well, and the reverse holds true. This kind of shared ownership is a stronger long-term guarantee of maintainability than any single team can offer on its own, and it's the primary reason this migration was worth undertaking. #### 2. Performance and Efficiency The second driver is more straightforward: Go, as a runtime, is materially better suited to the kind of high-throughput, low-latency authentication workloads that a national identity backend needs to sustain. In practice, this has translated into eSignet achieving meaningfully better throughput on comparable or smaller infrastructure footprints than the Java-based engine required. For adopters, this matters in very concrete terms: lower hosting and scaling costs from better throughput per unit of infrastructure, more headroom under peak load (such as large-scale enrollment drives or high-traffic authentication events), and a system that stays responsive as usage grows without a proportional increase in resource spend. ### The Approach: Building on Thunder, Not Apart From It #### Two Products Built for Two Different Problems It's worth being precise about what Thunder is, and isn't. Thunder was built by WSO2 as an enterprise identity and access management engine, designed to secure workforce identity, internal applications, and enterprise service ecosystems. eSignet exists to solve a different problem: it is a country- and government-focused digital identity layer, built specifically to implement the global interoperability standards that let a nation's foundational ID system work seamlessly across banking, healthcare, welfare, and every other sector that depends on trusted identity verification. [Thunder](https://thunderid.dev/) gave eSignet a mature, high-performance, Go-based identity core, but an enterprise-grade engine does not, on its own, make a standards-compliant national identity backend. That compliance layer is what the eSignet team has added on top of Thunder: FAPI 2.0 compliance, along with the assurance levels, consent architecture, and eKYC capabilities that are specific to eSignet's mandate. Thunder was not built with all of these standards natively; eSignet's engineering work is what makes the combined system compliant with them. #### One Codebase, Kept in Sync Rather than maintaining a Go-based engine as a separate, parallel codebase, eSignet is built as a layer on top of Thunder ID itself, using Thunder ID's repository as the foundation and adding the eSignet-specific product layer on top of it: its OIDC and FAPI 2.0 compliance behavior, consent handling, biometric and OTP authentication support, verified claims, and everything else that constitutes eSignet's product experience. This means eSignet's engine tracks Thunder's ongoing development directly. As WSO2 continues to develop and harden Thunder, eSignet inherits those improvements as a natural part of staying current with its upstream, rather than through a separate porting effort each time. The two projects develop in an ongoing collaborative relationship rather than a one-time handoff, which is precisely the sustainability model this migration was intended to create. ### What Stays the Same None of this is visible to the people eSignet ultimately serves, and that is by design. The eSignet user interface remains exactly as it was under the Java-based engine. End users authenticating through eSignet, whether via [OTP, biometrics, or password](/home/esignet-2.0.0/readme/features.md), will notice no difference in how the product looks, behaves, or responds. Nothing about the user experience has changed as a result of this migration. The same holds for [standards compliance](/home/esignet-2.0.0/readme/standards.md). eSignet's Go-based engine implements the full set of OpenID Connect, OAuth 2.0, and FAPI 2.0 requirements that the Java-based platform did. No feature, no compliance guarantee, and no integration contract has been dropped or diminished in the move. Relying parties integrating against eSignet's OIDC endpoints today will find the same standards-based surface they always have. In short: the engine underneath has changed meaningfully. What eSignet does, and what it guarantees to the people and systems that depend on it, has not. ### Why This Makes eSignet a Stronger Product Taken together, this migration strengthens eSignet along exactly the dimensions that matter most for infrastructure meant to serve at national scale: * **More durable, better resourced.** eSignet's core engine is now maintained by two engineering organizations instead of one, reducing the risk that comes with any single point of ownership over critical infrastructure. * **More efficient to run.** Better throughput on comparable infrastructure lowers the operational cost of running eSignet at scale, for MOSIP and for every adopter running it independently. * **No loss of trust or compatibility.** Every standard eSignet complied with before, it complies with now. Every integration built against it continues to work exactly as it did. * **Positioned to keep improving.** Because eSignet now develops in step with Thunder's own roadmap, it benefits on an ongoing basis from engineering investment happening outside its own team, rather than depending solely on its own resourcing. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.esignet.io/home/esignet-2.0.0/readme/migration-to-go.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.