Kafka SSO integration is two separate jobs. For people, the best tools are Kafka UIs with native SAML, OIDC or LDAP login that map identity provider groups to roles: Kpow, AKHQ and Kafbat UI, plus commercial consoles from Confluent, Conduktor and Redpanda. For services, the tools are Apache Kafka’s own SASL/OAUTHBEARER implementation, Strimzi’s OAuth library and cloud IAM plugins such as aws-msk-iam-auth. Kpow sits in the first group. Kpow is Factor House’s product, and I work at Factor House as a Solutions Architect, so it is scored on the same rubric and the same sources as every other option.
Kafka’s wire protocol has no concept of a browser login, and a UI’s SSO has no effect on how a producer authenticates. Most confusion in tool selection comes from treating the two as one purchase. Our Kafka authentication page covers listener and JAAS configuration for the broker side in detail. This page is for choosing tools once you know which half you are solving. Both halves sit under Kafka stream governance, and the complete Kafka guide covers the rest of the platform.
How to score a Kafka SSO tool
The rubric has criteria for each half, and the figure above lays out how the halves differ. A tool scores only on the half it addresses.
Human half, criterion 1: protocol and IdP coverage. Does the tool speak the protocol your identity team has standardised on? Banks and large enterprises often mandate SAML, newer stacks mandate OIDC, and many still run LDAP or Active Directory underneath both. A UI that supports only OAuth2 pushes a SAML shop into running a proxy in front of it.
Human half, criterion 2: group-to-role mapping. Nobody wants to maintain a second user directory for a Kafka tool. The tool should read roles from the IdP’s assertion or token and turn them into permissions, so joining or leaving a team is an IdP change and nothing else. The pattern works at scale: Sandy Yang, a staff engineer on TD’s Event Streaming Platform, described in her talk with us how TD gives people Kpow access based on their AD group, with production access limited to the operations team. One customer told Derek Troy-West, our co-founder and CEO, that they had each team create its own AD group with its own topic prefix, and that tenancy made it “easier for us to grant access” because users would not see resources that belong to other teams.
Human half, criterion 3: enforcement behind the login. SSO proves who someone is. It is only useful if every path into the tool, the UI and its API, enforces the permissions that identity carries. Read each tool’s documentation for the places it does not. What those permissions look like once identities arrive is compared in Kafka RBAC tools, and machine principals’ permissions in Kafka ACL management tools.
Machine half, criterion 4: token validation on the broker. Can the broker validate JWTs from your IdP itself, with issuer and audience checks, without a custom plugin? This is the difference between a supported configuration and a callback handler your team owns forever.
Machine half, criterion 5: operational cost. The two questions engineers ask here are whether token validation will slow high-throughput brokers, and what the exact sasl.jaas.config string is. Apache Kafka’s own configuration reference answers the first. The broker retrieves the IdP’s JWKS at startup and caches the keys, refreshing hourly by default and querying again only when a token carries a key ID it has not seen:
sasl.oauthbearer.jwks.endpoint.url=https://idp.example.com/oauth2/v1/keys
sasl.oauthbearer.jwks.endpoint.refresh.ms=3600000Validation happens when a connection authenticates, not per message, so throughput is not the constraint. What does bite is reachability. When I was working through telemetry design with our engineers, I wrote that “it’s safe to assume that just about every single deployment of kpow backend, will be denied egress to the internet”, and the same is true of most regulated Kafka topologies. Check that brokers and tools can reach the IdP’s endpoints, or use a file-based JWKS URL, which the same reference allows.
Securing human access to Kafka UIs and management tools
Kpow. What it is: Factor House’s Kafka management tool, self-hosted. Protocols: SAML, with integration guides for Okta, AWS SSO, Microsoft Entra ID and Keycloak, OpenID Connect with Okta, GitHub and generic providers such as Keycloak or Ping Identity, and LDAP, file or database login through Jetty’s JAAS modules. Role mapping: SAML roles come from the Roles attribute, or any attribute you name, such as Groups, and OIDC roles come from a configurable path in the access or ID token. Where it falls short: the docs note that Prometheus endpoints stay unauthenticated when authentication is on, so restrict them at the network. Detail in the Factor House section below. Source: Kpow authentication overview.
AKHQ. What it is: an open-source Kafka UI, Apache 2.0. Protocols: basic auth, LDAP, OIDC, GitHub, header-based auth from a proxy, JWT and AWS IAM. Its docs do not list SAML. Role mapping: AKHQ groups bind roles to resource patterns and clusters, and its OIDC config maps a claim such as roles to those groups through groups-field. Where it falls short: security is disabled by default, with anonymous users getting full access until you enable it, and its groups page warns that if the JWT signing secret is not set, “the API will not enforce the group role, and the restriction is in the UI only”. Source: AKHQ OIDC, AKHQ groups.
Kafbat UI. What it is: the actively maintained open-source fork of the original kafka-ui, Apache 2.0. Protocols: OAuth2 and OIDC, with provider guides including Microsoft Entra ID, Google and GitHub, and LDAP or Active Directory. Its docs do not list SAML. Role mapping: RBAC subjects can be OAuth roles, users, GitHub organisations or teams, Google domains, or LDAP groups. Where it falls short: its RBAC troubleshooting FAQ starts from “RBAC is enabled, I see no clusters in UI” and walks through tracing role extraction in the logs, so budget time to test IdP attribute mapping before rollout. Source: Kafbat UI OAuth2, supported identity providers.
Confluent Control Center. What it is: Confluent Platform’s management UI. Confluent’s documentation, SSO for Control Center overview page, says SSO requires an OIDC identity provider and does not support IdP refresh token rotation. Where it falls short: it is tied to Confluent Platform. Source: Confluent’s documentation (not linked).
Conduktor Console. What it is: a commercial Kafka console. Conduktor’s documentation, SSO configuration page, covers LDAP and OIDC, with guides for Okta, Entra ID, Keycloak, Auth0, Amazon Cognito, Google, JumpCloud and WorkOS, and group mapping from the IdP. The page is titled for LDAP and OIDC and does not describe SAML. Source: Conduktor’s documentation (not linked).
Redpanda Console. What it is: Redpanda’s web console. Redpanda’s documentation, Console authentication page, says OIDC login “requires an enterprise license”, and that Console reuses the OIDC access token to authenticate to Redpanda’s Kafka API over SASL/OAUTHBEARER, which is the only tool here that bridges both halves, for Redpanda clusters. Source: Redpanda’s documentation (not linked).
oauth2-proxy in front of a UI. What it is: an open-source reverse proxy that adds OAuth2 and OIDC login in front of any web application. Strengths: it can put SSO in front of a UI that has none. Where it falls short: the UI behind it still sees one anonymous or header-supplied user, so you get authentication without per-user permissions unless the UI reads identity headers, as AKHQ’s header auth does. Source: oauth2-proxy.
Securing machine-to-machine access to Kafka brokers
Apache Kafka SASL/OAUTHBEARER. What it is: Kafka’s built-in OAuth mechanism, introduced in KIP-255 with unsecured tokens for development, and extended with OIDC support in KIP-768. The Apache Kafka documentation says the default implementation “is only suitable for use in non-production Kafka installations” and that recent versions add production-ready implementations that work with an OAuth 2.0 identity provider. On the broker:
listener.name.sasl_ssl.oauthbearer.sasl.server.callback.handler.class=org.apache.kafka.common.security.oauthbearer.OAuthBearerValidatorCallbackHandler
listener.name.sasl_ssl.oauthbearer.sasl.oauthbearer.jwks.endpoint.url=https://idp.example.com/oauth2/v1/keys
sasl.oauthbearer.expected.issuer=https://idp.example.com
sasl.oauthbearer.expected.audience=kafkaOn clients, the client_credentials grant needs a client ID, a secret or signed assertion, a scope and the token endpoint. Strengths: no third-party code, issuer and audience validation built in, and the token’s subject becomes the principal your ACLs refer to. Where it falls short: it only validates JWTs, and authorization still comes from your ACLs or authorizer. Source: Apache Kafka SASL authentication.
Strimzi OAuth. What it is: Strimzi’s OAuth library for Kafka, usable with or without the Strimzi operator. Strengths: its README says it “supports more client and server workflows, has more configuration options, and works with both opaque and JWT access tokens” than the built-in implementation, and it adds token-based authorization through Keycloak Authorization Services, which the Strimzi operator lists as the only supported mechanism for its OAuth authorization mode. Where it falls short: the authorization side assumes Keycloak. Sources: strimzi-kafka-oauth, Strimzi OAuth 2.0 configuration.
Amazon MSK IAM. What it is: AWS’s client library that adds a SASL mechanism, AWS_MSK_IAM, so JVM clients authenticate and are authorized with IAM on MSK clusters. Strengths: no Kafka credentials to rotate, and IAM policies replace ACLs. Where it falls short: MSK only. Source: aws-msk-iam-auth.
Confluent Platform and Confluent Cloud. Confluent documents OAuth and OIDC for its own brokers and CLI, and its RBAC. Where it falls short: it applies to Confluent’s distributions. Source: Confluent’s documentation (not linked).
Tools compared
| Tool | Half | Protocols | Group-to-role mapping | Enforcement gaps to know | Operational cost | Source |
|---|---|---|---|---|---|---|
| Kpow | Human | SAML, OIDC, LDAP, file, DB | Roles attribute or any SAML attribute, OIDC role path, LDAP roles | Prometheus endpoints unauthenticated | Environment variables and one RBAC YAML file | Kpow docs |
| AKHQ | Human | LDAP, OIDC, GitHub, header, JWT, basic | Groups mapped to roles and resource patterns | Open by default. UI-only restriction if JWT secret unset | YAML config, free | AKHQ docs |
| Kafbat UI | Human | OAuth2 and OIDC, LDAP | Roles, users, orgs, teams, domains, LDAP groups | Silent mismatches between IdP attributes and config | YAML or environment variables, free | Kafbat docs |
| Confluent Control Center | Human | OIDC | Through Confluent RBAC | Confluent Platform only | Part of Confluent Platform | Confluent's documentation (not linked) |
| Conduktor Console | Human | LDAP, OIDC | IdP groups to Console groups | Commercial | Commercial licence | Conduktor's documentation (not linked) |
| Redpanda Console | Both, for Redpanda | OIDC | Through Redpanda RBAC | Enterprise licence required for OIDC | Enterprise licence | Redpanda's documentation (not linked) |
| oauth2-proxy | Human | OAuth2, OIDC | None inside the UI unless it reads headers | Per-user permissions missing behind it | One more proxy to run | GitHub |
| Kafka SASL/OAUTHBEARER | Machine | JWT via OIDC client credentials | Token subject becomes the ACL principal | Default unsecured mode is not for production | Built in, JWKS cached on broker | Apache Kafka docs |
| Strimzi OAuth | Machine | JWT and opaque tokens | Keycloak Authorization Services | Authorization assumes Keycloak | Extra library on brokers and clients | GitHub |
| aws-msk-iam-auth | Machine | AWS IAM | IAM policies | MSK only | Library on each client | GitHub |
A complete setup usually has one entry from each half, and teams running several clusters should check the SSO story across all of them, which Kafka multi-cluster tools covers. The UI row decides how people get in, and the broker row decides how services get in. Neither replaces the other.
How Factor House approaches it
Kpow is a human-access tool. It authenticates people through your IdP and then authorizes every action they take in the UI and API against Kpow’s own RBAC, which is where the group mapping lives. A SAML setup names the attribute that carries roles, and a policy file grants actions to those role names:
saml:
role_field: "Groups"
admin_roles:
- "kafka-admin"
policies:
- resource: ["cluster", "*", "topic", "payments.*"]
effect: "Allow"
actions: ["TOPIC_INSPECT"]
role: "payments-engineers"The RBAC documentation covers the rest: Deny wins where policies overlap, anything unmatched is implicitly denied, and every action is recorded in the audit log with the user’s identity from the IdP. Multi-tenancy is the step after SSO for shared clusters, because a tenant assigned to a role restricts which topics, groups and connectors that role can even see.
On the machine half, Kpow is a Kafka client like any other, so it uses whatever your brokers require: SASL/SCRAM, mTLS, OAUTHBEARER through the standard client properties, or MSK IAM, which Kpow’s MSK guide documents with AWS_MSK_IAM. It does not issue or validate tokens for your applications. That half belongs to the broker and your IdP.
Where Kpow does not win: its OIDC integration guides cover Okta and GitHub by name plus a generic provider, so a less common IdP means following the generic guide, and Prometheus endpoints need network-level protection. For how SSO roles become tenant views across teams, see Kpow multi-tenancy.
To see what your IdP roles would govern, open the Kpow demo and try the data inspect, topic and consumer group screens that RBAC policies control, then follow the SAML or OpenID guide to connect your own identity provider.
Product demo · 1 min
Apache Kafka access policies & SSO: Kpow demo
Chad Harris covers access policy configuration in Kpow: exactly which permissions are assigned to the role currently logged in, and how SSO integration with OAuth, SAML, Entra ID, and other providers drives permission assignment from your existing identity roles and groups.
Kpow live demo
See SSO-backed Kafka access in action
Explore Kpow in a live environment and picture it behind your identity provider, with every action recorded against a named user.
For platform and security teams who have to show who can do what.
Try the Kpow demoFAQ
Does Kafka support SSO natively?
Not for people. Apache Kafka authenticates connections, not browser users, so SSO for humans comes from the UI or console you put in front of it. For services, Kafka’s SASL/OAUTHBEARER mechanism can validate JWTs issued by the same identity provider.
Can I use Okta or Entra ID to authenticate Kafka clients?
Yes, through SASL/OAUTHBEARER with the OIDC client_credentials grant. The client fetches a token from the IdP’s token endpoint and the broker validates it against the IdP’s JWKS. Authorization still comes from ACLs keyed on the token’s subject.
Does OAUTHBEARER token validation slow down Kafka brokers?
Not per message. The broker validates a token when a connection authenticates, using JWKS keys it caches and refreshes hourly by default. The practical risk is the broker being unable to reach the JWKS endpoint, not throughput.
Which open-source Kafka UI supports SAML?
Of the open-source UIs covered here, neither AKHQ nor Kafbat UI documents SAML. Both support OIDC and LDAP. Kpow, which is commercial, supports SAML in its Enterprise edition, with guides for Okta, AWS SSO, Entra ID and Keycloak.