Open Source and Self-Hosted Auth for React in 2026

Installing an identity provider and connecting it to a React application is usually the easy part. Most open source and self-hosted authentication guides focus on getting to that point, comparing features, licenses, and initial setup.

The more important questions appear later. Who applies a security update when a vulnerability is disclosed? How are certificates and signing keys rotated? What happens when the deployment is several major versions behind, or the engineer who originally set it up has moved on?

Self-hosting is therefore an operational decision as much as a technology or licensing decision. This guide starts with that operational responsibility, then looks at the available approaches, the open source landscape, and what React teams should consider when choosing and running a self-hosted identity provider.

What self-hosting actually means​

Self-hosting means the identity software runs on infrastructure you control and your team is responsible for operating it.

It does not tell you whether the software is open source, proprietary, or written by your own team. Those are separate decisions.

In practice, there are three main approaches.

Option one: build authentication yourself​

This is usually described as rolling your own auth. Your team owns the user store, password handling, sessions or token issuance, recovery flows, and the application logic around them.

Of course, nobody should implement password hashing or signature verification from scratch. Those functions should come from well-tested libraries. But using libraries does not remove the operational responsibility. Security fixes still need dependency upgrades, testing, and releases. Algorithms can be deprecated, libraries can introduce breaking changes, and security reviews can require changes to implementations that have been running for years.

The same pattern appears when requirements grow.

Assume an audit introduces an MFA requirement. With an identity product, much of this is configuration. With a custom implementation, the team first needs to decide which factors are supported, how enrollment works, how users recover when a device is lost, how administrators handle recovery, and what support processes are required.

Authentication quickly becomes more than login code.

The useful question is therefore not whether the team is capable of building authentication. Most experienced development teams are. The question is whether identity should become something the team owns for the next several years, including its security, compliance, protocol support, and operational lifecycle.

Building authentication internally makes sense when both of the following are true: the team has genuine identity expertise, and there is a requirement existing products cannot meet.

Those cases do exist. A company may itself be building an identity product, operating in an environment where third-party software cannot run, or using an identity model that does not fit available products. Outside those cases, building authentication can be useful for learning, but using the same implementation as a production identity platform is a different decision.

Option two: run open source identity software​

This is what many teams mean when they talk about self-hosted authentication. An open source identity provider is deployed on infrastructure controlled by the organization.

The value of open source here is not only that there may be no software license fee. It also provides access to the source and the freedoms that come with the license.

Security teams can inspect the implementation. Organizations can perform their own security analysis. The software can be modified when a requirement is not available out of the box, and it can be deployed in environments where a public managed service is not possible.

Open source also does not necessarily mean operating without support.

Many open source identity providers have a commercial organization behind them offering production support, tested updates, migration guidance, and support commitments. This creates a useful middle ground between running everything independently and adopting a proprietary identity product.

The organization keeps the open source software and deployment control while deciding separately whether commercial support is required.

Another useful model is an open source identity provider that is also available as a managed service. In this case, self-hosted and SaaS can become deployment choices around the same underlying software rather than completely separate products.

This can simplify future migration, provided the protocol and application integration surfaces remain compatible between the two deployment models.

Option three: run proprietary identity software​

The third approach is commercially licensed identity software running on infrastructure controlled by the organization.

This is common in enterprise environments, particularly where there are regulatory, operational, or support requirements.

The main benefit is accountability. There is a vendor, a support contract, a release process, and an organization responsible for product-level issues. Enterprise capabilities are also more likely to be delivered as part of a supported product rather than assembled from multiple components.

The trade-off is reduced independence.

The complete implementation may not be available for inspection or modification. Upgrade timing follows the vendor's supported release path, and requirements outside the supported extension model depend on what the vendor chooses to provide.

Migration can also be more expensive if applications rely heavily on proprietary integration surfaces rather than standards such as OAuth 2.0, OpenID Connect, SAML, or SCIM.

Wiring a React app to a self-hosted provider​

Once you have selected an identity provider, the next question is how the React application should integrate with it.

There are three common approaches. They are not different authentication models, but different levels of abstraction over the same OpenID Connect flow. The level you choose determines how much of that flow your application needs to manage.

For self-hosted providers, this also affects product choice. Almost every conformant OpenID Connect provider works at the protocol level. A React SDK depends on whether the provider or its community maintains one, and SDKs with ready-made React components are less common.

Level 1: integrate at the protocol level​

At the lowest level, the application integrates directly with OpenID Connect using a general OAuth 2.0 or OpenID Connect client library.

The application handles the authorization redirect, code exchange, token storage, expiry, refresh, logout, and processing of the authentication response. This gives the most control, but also leaves the most responsibility with the development team.

The main advantage is portability. A conformant OpenID Connect provider exposes a discovery document describing its authorization endpoint, token endpoint, signing keys, and supported capabilities. If the integration is built around this standard metadata rather than provider-specific APIs, moving between providers can become largely a configuration change.

This level is useful when portability matters, when every step in the authentication path needs to be reviewed, or when the selected provider does not have a suitable React SDK.

The trade-off is expertise. The team still needs to understand OpenID Connect well enough to handle authentication state, token storage, refresh, and logout correctly.

Level 2: use a headless React SDK​

The second approach is a provider-specific or community-maintained React SDK that handles the OpenID Connect mechanics while leaving the UI to the application.

The SDK typically manages sign-in, token storage, expiry, refresh, and logout, then exposes hooks or utility functions such as:

signIn()
signOut()
isAuthenticated
user

The application still owns the sign-in button, loading state, profile page, errors, and the rest of the authentication UI.

This works well when the application has its own design system but the team does not want to maintain the protocol flow itself.

For self-hosted providers, also check who maintains the SDK. If it is community-maintained, its activity, ownership, release history, and React compatibility become part of the dependency decision.

Level 3: use a React SDK with ready-made components​

The highest level provides both authentication hooks and ready-made React components.

Conceptually, the application may use components such as:

<SignIn />
<UserProfile />
<SignOut />

This provides the fastest route to a working authentication experience, while good SDKs still allow the components to be styled or extended.

The trade-off is tighter coupling. At Level 1, the application mainly depends on OpenID Connect. At Level 2, it depends on the SDK API. At Level 3, provider-specific components also become part of the React component tree.

Most component-based SDKs still expose the lower-level hooks underneath, so individual screens can use custom UI when more control is required.

The open source and self-hosted landscape in 2026​

Six options come up repeatedly when React developers look at open source authentication and self-hosted identity providers.

A useful way to compare them is to look beyond the feature checklist and ask what each project was originally designed to solve. That design centre still shows up in what the product makes easy, what the application team needs to build around it, and how well it fits when requirements grow beyond basic login.

For React developers, there is another important difference: the integration experience. Some providers expose standard OpenID Connect and leave the React integration largely to the application team. Others provide first-party React SDKs, hooks, and reusable components that remove much of the authentication-specific code from the application.

The comparison therefore looks at two things: what the identity platform provides as requirements grow, and how much React-specific integration it provides out of the box.

authentik​

authentik is designed to make running a self-hosted identity provider relatively straightforward. It supports the authentication capabilities most application teams expect and is OpenID Certified.

For React developers, the main limitation is the application integration layer. authentik exposes a standard OpenID Connect interface, but there is no first-party React SDK or reusable React component library. In terms of the integration levels discussed earlier, it effectively stops at Level 1.

That is a real weakness if the team wants authentication to fit naturally into the React development experience. You can still integrate using a general OIDC library, but authentication state, token lifecycle, UI integration, and common components remain things the application team needs to assemble.

Authelia​

Authelia comes from a different starting point. It was originally designed to put authentication in front of applications through a reverse proxy, although it can now also act as an OpenID Connect provider.

For React, this is again primarily a Level 1 integration. The application talks to Authelia using OpenID Connect, but there is no first-party React SDK providing hooks, authentication state management, or reusable components.

This is less of an issue when the goal is mainly SSO for self-hosted applications. It becomes a more visible weakness when authentication is part of the application itself, because more of the React-specific integration remains with the development team.

Keycloak​

Keycloak is an established option in this list, with broad identity capabilities and many years of community and production use.

React applications normally integrate through OpenID Connect and Keycloak's official JavaScript adapter, keycloak-js. The adapter handles much of the browser-side authentication flow and token lifecycle.

The limitation is that the abstraction does not continue into React itself. Keycloak does not provide a first-party React SDK with hooks and reusable authentication components for application developers. Community React integrations exist, but that means taking another dependency in the authentication path rather than using something maintained as part of Keycloak itself.

For React developers, this is a weakness compared with products that provide complete Level 2 and Level 3 support. Keycloak gives you a mature identity platform underneath the application, but more of the React authentication layer and UI remains yours to build.

SuperTokens​

SuperTokens has gained some community traction, particularly among application developers looking for an SDK-led authentication model.

Its official React SDK provides both lower-level authentication APIs and prebuilt authentication UI, covering the Level 2 and Level 3 models described earlier. Authentication state, sessions, token handling, and common UI flows can therefore be handled through the SDK rather than assembled separately by the application team.

The architectural difference is on the server side. The self-hosted SuperTokens model is not equivalent to running a general-purpose OpenID Connect authorization server, particularly when the requirement is to operate one identity provider that serves multiple independent applications and clients through standard OIDC.

WSO2 Identity Server​

WSO2 Identity Server combines an enterprise identity platform with a first-party React developer experience.

Its React SDK covers both Level 2 and Level 3. Developers can use hooks and APIs when they want complete control of the interface, or use reusable components for common authentication and user-management experiences.

This includes components for sign-in, sign-up, sign-out, authentication state, user profile and self-service experiences, as well as organization-related use cases.

For React developers, this removes a meaningful amount of authentication-specific application code. A team can start with reusable components, customize the UI when required, or drop down to the lower-level SDK APIs without changing the identity provider underneath.

The platform also covers requirements that commonly appear later, including B2B organizations and newer agent identity scenarios. This becomes relevant when an application starts with login but later needs to support business customers, delegated administrators, or agents acting on behalf of users.

ThunderID​

ThunderID takes a developer-first approach from a much newer identity architecture.

Its official React SDK covers both Level 2 and Level 3. It provides hooks for applications that want full UI control, together with reusable components for sign-in, authenticated-state rendering, user information, and other common authentication experiences.

It also provides first-party integration with React Router, reducing some of the routing and authentication-state plumbing that application teams would otherwise need to build.

For React developers, this is one of ThunderID's clearer advantages. SDK and framework integration are part of the project's design rather than something added around the identity server later.

The trade-off is maturity. ThunderID is much newer than the established projects in this list, so production history and the breadth of the surrounding identity feature set still need to be considered separately.

React integration comparison​

For React developers, the important difference is how much authentication-specific code remains inside the application.

Level 1 provides the strongest standards-based portability, but the application team owns more of the integration. A first-party Level 2 SDK removes much of the authentication state and token-lifecycle plumbing, while Level 3 also provides reusable components for common authentication experiences.

The absence of Level 2 or Level 3 support should be treated as a real weakness for React developers, not simply a missing convenience library.

This does not make a Level 1-only project a weaker identity provider overall. It means it provides a weaker React developer experience, which is an important distinction when React developers are the audience making the choice.

What running an identity provider involves​

Once an identity provider is self-hosted, it becomes infrastructure the organization operates.

The following areas should therefore be part of the product evaluation rather than something considered after production deployment.

Security updates​

Security fixes usually have the shortest operational timeline.

Getting the fix is only the first part. The more important question is how quickly and safely that fix reaches production.

Before an urgent vulnerability appears, the team should already know who owns identity updates, how an advisory moves from publication to deployment, what approvals are required, what test coverage exists, and which parts of the process can be automated.

It is also useful to measure the actual time required to move a normal update from availability to production. That number is a better indication of the real exposure window than an estimate made during an incident.

Commercial support can improve access to fixes, tested updates, and guidance, but under a self-hosted model the deployment process still belongs to the organization.

Upgrades​

Upgrade planning should start during product selection.

Identity software sits on the security boundary of many applications, so remaining on unsupported versions for long periods creates both security and operational risk.

Check the release cadence and supported-version policy together. A product releasing frequently but supporting older versions for a long period creates a different operational model from one with a shorter support window.

It is also important to confirm whether documented major-version upgrade procedures exist.

Customizations need particular attention. Authenticators, claim mappings, provisioning connectors, UI customizations, and other extensions are often the areas most affected during upgrades. Extensions built using documented extension points generally create a better upgrade path than changes depending on internal implementation details.

Finally, decide who will perform the upgrades.

The organization can build that capability internally, use a service provider, or purchase commercial support that includes migration guidance. Problems usually appear when this ownership is left undefined until the system is already several versions behind.

Availability and scaling​

Identity often starts as a dependency for one application and later becomes a shared dependency across many applications.

At that point, identity availability becomes application availability.

Depending on the product, a production deployment may require multiple nodes, shared session state, load balancing, and a database with its own high-availability design.

The evaluation should therefore include published throughput and concurrency numbers, recommended deployment topologies, and how the product scales as usage increases.

It is also useful to size for expected growth rather than only current traffic.

Identity is one of the more difficult infrastructure components to replace because changing the identity provider can affect every integrated application. Discovering later that the deployment architecture cannot meet expected scale can turn into a large migration project.

Secure configuration​

An identity provider holds credentials and issues tokens used across applications, so its configuration is part of the security boundary.

TLS certificates need a reliable renewal process.

Token-signing keys also need rotation. This is particularly relevant for APIs used by React applications because APIs commonly cache the provider's public signing keys. A rotation without an appropriate overlap period can cause otherwise valid tokens to fail validation.

Secrets accumulate around the identity provider as well, including database credentials, keystore passwords, and client secrets used for downstream integrations. These should be managed through an appropriate secrets-management mechanism rather than stored in source repositories or plaintext configuration.

The deployment itself also needs hardening. Administrative interfaces should not be exposed unnecessarily, default administrator credentials should be changed or removed, unused endpoints and protocols should be disabled, and administrative access should be separated appropriately from application deployment responsibilities.

Backups require the same security considerations as production data because an identity database backup contains user information.

More importantly, the restore process should be tested. Having a backup file and having a working recovery procedure are not the same thing.

Keeping the deployment reproducible from version-controlled configuration and automation makes most of these activities easier. Rebuilding the environment should be a known operational procedure rather than something that depends on the person who originally configured it.

Who should self-host?​

Self-hosting is not automatically the right choice for every organization.

• Solo developer or small team: Operating an identity provider is usually not the best use of limited engineering time. A managed service can be a better starting point, particularly when it provides a free tier or low-cost entry point. An open source identity provider that is also available as SaaS can be especially useful. The team can start without running infrastructure and later move to a paid tier or self-hosted deployment as requirements change, while potentially keeping the same underlying identity technology.

• Scaling startup or SME with a platform team: A platform team may be fully capable of running an identity provider, but the question is whether doing so is the best use of that engineering capacity. A team may initially use SaaS and later find that increasing usage, deployment requirements, or cost makes self-hosting attractive. At that point, an open source product can provide several options: operate it internally, rely on community support, or add commercial support while retaining control of the deployment.

• Regulated enterprise: Requirements such as data residency, auditability, procurement, and deployment control can make self-hosted or private-cloud identity a natural fit. The distinction between proprietary and open source self-hosted software is sometimes reduced by licensing cost, but open source provides other properties that may be more important. The organization can inspect the source, run its own security analysis, understand the implementation in more detail, and develop extensions where the architecture allows it. Those freedoms can matter even when reducing software cost is not the primary objective.

• Air-gapped or restricted network: In an air-gapped or restricted environment, a public managed service may not be available at all. The evaluation then becomes more practical: can the software be installed, operated, and updated without outbound internet access, and does the license permit that deployment model? Open source can provide an advantage here because the organization retains access to the software and can inspect and adapt it within the constraints of the network.

Where to go from here​

Self-hosting determines who operates the identity system. Open source determines what freedoms you have over the software. Commercial support determines how much of the operational responsibility you want to carry alone.

Those are related decisions, but they are not the same decision.

If your application is simple and a managed service meets the requirement, there may be little reason to operate an identity provider yourself. Self-hosting starts to make more sense when deployment control, regulatory requirements, cost, customization, or the need to share identity across multiple applications and systems becomes important.

If WSO2 Identity Server fits those requirements, the Apache 2.0-licensed software can be deployed and operated independently, while commercial support remains a separate choice.

The useful approach is to keep these decisions separate: choose the identity software based on the capabilities and architecture you need, choose the deployment model based on your operational constraints, and decide how much support you need based on what your team is prepared to operate over the long term.