Accounts and SSO: Part 2 — FusionAuth

FusionAuth — an authentication and user management server that developers built around an API: anything you can do in the admin panel can be done via REST API. You can host it on your own servers for free or use the cloud version from the vendor.

Licensing model

The main thing to know before choosing: FusionAuth is not an open source project. The Community edition is free and can be installed on your own servers, but the code is closed. This distinguishes it from Keycloak, where all code is open under the Apache 2.0 license.

Pricing as of September 2026 (according to the FusionAuth website):

Running FusionAuth on your own servers is allowed on all plans. The SAML v2 protocol is included in all plans, including the free one — the previous claim that SAML is only available for a fee is incorrect.

Features

• OAuth 2.0, OpenID Connect and SAML v2 — sign-in for web and mobile apps and enterprise systems.
• User registration and profiles, application-level groups and roles.
• Multi-factor authentication and login via external providers.
• An API for every action and client libraries for popular languages — useful when accounts are created from code, for example during registration in your product.
• Webhooks for events: registration, login, user changes.

How to run

The official way to try it is Docker Compose from the fusionauth-containers repository:

curl -o docker-compose.yml https://raw.githubusercontent.com/FusionAuth/fusionauth-containers/main/docker/fusionauth/docker-compose.yml
curl -o .env https://raw.githubusercontent.com/FusionAuth/fusionauth-containers/main/docker/fusionauth/.env
# in .env replace the database passwords
docker compose up -d

The installation consists of FusionAuth itself, a database (PostgreSQL by default or MySQL) and a search service OpenSearch or Elasticsearch. According to the documentation search is formally optional, but it is present in the standard build. The admin panel is exposed on port 9011; on first login a setup wizard runs.

For production you need the same precautions as for any authentication server: HTTPS on a reverse proxy, a database with backups, restricted access to the admin panel and regular updates.

Comparison with Keycloak

Limitations

• Closed source. You cannot audit or fix the code yourself, and the terms of the free edition are determined by the vendor.
• Price of paid plans. The gap between Starter and Essentials is large; for a small company paid features may be unaffordable.
• Russia. The cloud version and paid plans are paid with a foreign card; Visa and Mastercard issued in Russia do not work abroad. The free edition on your own server in Russia does not depend on payment, and user data stays with you, which complies with the requirement to store citizens’ personal data in databases located within the country.

Common mistakes

• Assuming FusionAuth is an open source project and planning for a code audit or fork.
• Leaving the database passwords from the example .env.
• Exposing port 9011 with the admin panel to the internet without a reverse proxy and access restrictions.
• Not making database backups: all users and settings are stored there.

When to choose

FusionAuth is convenient if you are building a product and want to manage users from code via a clean API, and open source is not a requirement. If openness, a large community and integration with corporate directories are important, Keycloak is a more logical choice.