Keycloak License Official

The keycloak license official terms use the open-source Apache License 2.0 for all users. You can download, run, and change the software for free in any company setup. Teams often start by setting up one main realm for all their internal users. They map broad group roles so developers can log in to databases and servers. When those roles are too wide, one login gives too much power across systems.

How the keycloak license official terms work in your setup

The keycloak license official rules let your team run the identity server without fees. You do not pay per user or per login event under the Apache license. Your team gets full control over the source code and all standard login flows. You can connect the identity server to your user directory and issue web tokens. Those tokens carry user identity and role claims to your internal apps and tools.

Admins set up realms to keep different teams or projects separate from each other. Inside a realm, you create client entries for each app that needs user logins. You also define roles and attach them to groups of engineers or support staff. When a user logs in, the server checks their password and second factor code. Then it sends a signed token back to the app to start a session.

Because the license allows custom code, teams often build custom plugins for special checks. You can write Java extensions to change how logins work or add new screens. Your team owns the work of patching and updating the server over time. If you want vendor support, you can buy a paid support plan from vendors. The core open-source project stays free to use in test and production setups.

What native identity setup solves and what it leaves open

Setting up an open-source identity provider solves the problem of scattered user accounts. Your team gets one place to turn off logins when a person leaves. You can enforce multi-factor login rules for every person on your engineering team. Apps do not need to store passwords or manage password reset emails anymore. They just trust the signed token from your central login server.

Still, an identity server only checks who a user is at the front door. Once a developer logs in to a database or server, the token check ends. The identity tool cannot see what SQL queries or shell commands run next. If an engineer has a write role, they can drop tables or read secrets. The login log shows they entered, but not what data they pulled out.

This leaves a big gap during audits and day-to-day production support work. Teams end up creating dozens of narrow roles to limit what people can touch. Managing all those roles across every database and cluster takes hours every week. Even with strict roles, a single valid session can still return raw private data. Masking fields like emails, phone numbers, card numbers, or national IDs requires deeper inspection. You need controls that work on individual queries and commands while the session runs.

How to plan your identity and role architecture

Start by keeping your identity provider focused on verifying users and group memberships. Map your company directory groups to clean, high-level roles inside your login realm. Avoid putting fine-grained database table permissions inside your main identity tokens. Keep token lifetimes short so stolen or cached tokens expire within a few minutes. Require a fresh login check before anyone starts a high-risk production task.

Next, separate the act of logging in from the act of running commands. Use your identity server to prove who the engineer is before they start work. Then pair that identity with runtime checks that inspect every query or command. When sensitive data returns, masking rewrites matched fields in results before they reach screens. This keeps your login setup simple while protecting your production data during active sessions.

Govern statements and responses across databases and APIs

Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.

First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.

Frequently asked questions

Is the keycloak license official version free for commercial use?

Yes, the project uses the Apache License 2.0 for all its core code. You can run it in commercial products and internal company systems at zero cost.

Do we need to open source our own apps when using it?

No, the Apache License 2.0 does not force you to share your app code. You only need to follow the license terms if you distribute modified server code.

Does the identity server log the database queries a user runs?

No, the identity server only records login events and token issue times. It cannot see or control the queries or commands run inside a database session.

Related guides

• Identity Based Firewall
• Infrastructure Quality Assurance
• Integrate Monitoring Alerts with Slack and Pagerduty