Client Flow for OAuth-OIDC using RBAC in Confluent Platform Clusters

The flow of interactions between a client, an identity provider (IdP), a Confluent Platform service, and the Metadata Service (MDS) when using OAuth-OIDC with role-based access control (RBAC) is shown in the following diagram. The diagram and subsequent steps provide detailed explanations of the processes involved.

In the following diagram:

  • Client: the Kafka client or application that wants to access a resource in a Confluent Platform service.
  • Confluent Platform service (“CP_Service”): the service that hosts the resource. Supported services include Confluent Server brokers, Kafka Connect, REST Proxy, Schema Registry, and ksqlDB.
  • Identity provider (“IdP”): the identity provider that issues JWT tokens to the Kafka client or application.
  • Metadata Service (“MDS”): the Confluent Platform component that provides metadata about your Confluent Platform cluster to the client or application and enforces access control policies.
Client credential flow using RBAC with OAuth-OIDC in Confluent Platform clusters

Step 1 - Client fetches JWT token (or access token) for authentication from the IdP

The client initiates the process by sending its credentials to the IdP. The IdP authenticates the client based on these credentials and returns a JWT token (“Return JWT”). This JWT token is used by the client to authenticate requests to the Confluent Platform service (“CP_Service”).

Step 2 - Confluent Platform service validates the incoming client request using JWKS

JWKS (JSON Web Key Set) is a set of keys containing the public keys used to verify any JSON Web Token (JWT) issued by the authorization server. In the flow, when the Confluent Platform service (“CP_Service”) needs to validate a JWT, it checks if the JWKS is available (“JWKS not cached or expired”). When the JWKS is unavailable, the Confluent Platform service requests it from the IdP (“Request jwks”). The IdP then returns the JWKS to the service (“Return jwks”), which it can use to validate incoming JWTs.

Step 3 - Confluent Platform service validates JWT token from the client

When the Confluent Platform service (“CP_Service”) receives a request from the client with a JWT token (“Request resource with JWT”), the token must be validated to ensure it’s legitimate and hasn’t been tampered with. The Confluent Platform service uses the previously fetched JWKS to validate the token. If the JWKS is already cached and valid, the cached JWKS is used to validate the token (“Validate token with local cached jwks”). If the token is valid, the process moves to the authorization step.

Step 4 - Confluent Platform service authorizes client using RBAC

After the JWT token is validated, the Confluent Platform service (“CP_Service”) extracts the principal (or user identity) from the token. This identity is used to determine the RBAC roles and permissions associated with the principal, based on the RBAC policies in the system. Subsequently, the Confluent Platform service (“CP_Service”) seeks authorization from the MDS (“Request authorization” with “CP_Service” token), providing the necessary credentials and the extracted principal. Upon verification by the MDS that the principal possesses the requisite permissions (“Authorization successful”), it authorizes the client to access the desired resource through the Confluent Platform service (“CP_Service”).

After authorization, the client can use the Confluent Platform service (“CP_Service”) to access the requested resource.