Why We Chose Keycloak: Enterprise SSO for AI Security Platforms

For a security product, authentication is not a feature — it is the foundation everything else is trusted on. A platform that scans for leaked secrets and governs AI agents cannot ship hand-rolled auth and ask enterprises to trust it. So when we hardened Netallion for enterprise buyers, the identity layer was the first thing we rebuilt — moving from a self-issued JWT scheme to Keycloak as our OIDC identity provider.

The problem with hand-rolled JWT

Early on, the API issued its own JSON Web Tokens signed with a shared symmetric secret (HS256). It works in a demo, but it carries real liabilities for an enterprise security product:

• Symmetric signing — the same secret that verifies a token can also mint one. Any service that needs to validate tokens must hold signing power.
• No key rotation — rotating a shared secret means a coordinated flag day across every service.
• No MFA or SSO — multi-factor and SAML/OIDC single sign-on are exactly what enterprise security teams require, and bolting them onto a custom scheme is a project in itself.
• No central session control — revoking access, enforcing password policy, and auditing logins all have to be reinvented.

What Keycloak gave us

Keycloak is a mature, open-source identity and access management server that speaks OIDC and SAML. Adopting it replaced our custom code with standards:

RS256 with key rotation

Tokens are now signed with asymmetric RS256. Services verify them against Keycloak's published JWKS using the key id (kid) in the token header, so signing keys can rotate without downtime and verifiers never hold signing power. Every token is checked for the right audience and authorized party before it is trusted — a token minted for a different client in the realm is rejected.

Centralized MFA and SSO

Multi-factor authentication, password policy, and session management are configured once in the realm and apply everywhere. Enterprise customers can federate their own identity provider over SAML or OIDC, so their users sign in with corporate credentials and your security team keeps central control of access.

Realm-based multi-tenancy

A single realm with scoped client roles gives us a clean separation between platform staff, tenant administrators, and end users — the role model the rest of the product's authorization builds on.

The marketplace constraint

The hard part was doing all of this without breaking the Microsoft Marketplace purchase flow. Buying through Azure Marketplace authenticates the purchaser with Microsoft Entra ID and hands off a subscription token that has to be resolved and activated. Our auth layer had to welcome a user arriving mid-purchase from Entra, link them to the right tenant, and complete activation — all while still offering OIDC sign-in and federated SSO for everyone else.

Keycloak's support for identity brokering and standard OIDC made this tractable: the marketplace identity is one federated path among others, not a special case bolted onto a custom token scheme. The purchase flow stayed intact, and enterprise SSO came along for the ride.

The takeaway

If you are building a B2B security platform, treat identity as core infrastructure, not a checkbox. Standards-based OIDC with asymmetric signing, key rotation, centralized MFA, and federated SSO are what move you from "works in a demo" to "passes enterprise procurement." For us, Keycloak was the shortest path to all of it.