Claim Validation for OAuth JWT tokens on Confluent Platform

Confluent Platform clients, whether a producer/consumer client application or a Confluent Platform service, must authenticate via an Oauth-compliant JSON Web Token (JWT). Every OAuth-based authentication request in Confluent Platform adheres to the same token validation process.

Token validation process

The following diagram depicts the token validation process at a high-level:

OAuth authentication request high-level flow

  1. Client credentials.

    A client that must authenticate to another service requests an OAuth token from an OIDC-compatible identity provider (IdP). The client provides its credentials to the IdP. During the client application deployment both the client credentials and the IdP endpoints are made available to the client application.

  2. IdP returns an OAuth JWT token.

    The IdP verifies the incoming client credentials and returns an OAuth token in JWT format. The OAuth token has all the client identity details such as unique id, groups, and scope and more. The token also has other attributes to verify the client authenticity such as signature, audience, and issuer and so forth.

    Each IdP has a token configuration it defines for an individual client application or a set of applications. An IdP’s token configuration specification can impact the actual payload of the JWT.

  3. Client sends an authentication request to the server with an OAuth token provisioned by the IdP.

  4. The server authenticates the incoming client request by validating the OAuth token.

    The tokens are validated by the server via JSON Web Key Set (JWKS). These are a set of public cryptographic keys which the Confluent Platform uses to verify a token’s authenticity. The JWKS includes information such as the signature, expected audience, expected issuer, expected JTI/UTI and more.

    The Confluent Platform server configuration specifies the expected audience claim value, issuer value and other attributes required for successful validation. When validations are successful, the server authenticates the client request.

Claim validation behavior in Confluent Platform version 7.7.2 and later

sub
A subject identifier claim. This claim is required for Confluent Platform services but optional for Kafka listeners. To specify that a different claim act as the sub value, configure the oauthbearer.sub.claim.name property.
jti

An optional token identifier claim. You can configure whether Confluent Platform checks for the jti claim. By default the check is enabled, though Confluent Platform does not use the claim in token validation. The following table shows how and where to configure this behavior:

Service Property to set
Kafka listener.name.<listener-name>sasl.oauthbearer.jti.validation.enabled
MDS confluent.metadata.server.oauthbearer.jti.validation.enabled
Confluent Platform services oauthbearer.jti.validation.enabled

When set to false, this property turns off the check. If the claims are present, Confluent Platform ignores them.

iat

An optional claim with the time at which the JWT was issued. You can configure whether Confluent Platform checks for the iat claim. By default, the check is enabled. The following table shows how and where to configure this behavior:

Service Property to set
Kafka listener.name.<listener-name>sasl.oauthbearer.iat.validation.enabled
MDS confluent.metadata.server.oauthbearer.iat.validation.enabled
Confluent Platform services oauthbearer.iat.validation.enabled

When set to false, this property turns off the check. If the claims are present, Confluent Platform ignores them.

aud

Intended audience of the token and it typically includes the client ID of the application making the authentication request. The service configuration controls whether this claim is required or optional.

If you want Confluent Platform to use the aud value when validating a token, configure oauthbearer.expected.audience in the service properties. You can turn off the aud validation by removing this property from the service properties file.

iss
A required claim it identifies the server that issued this token.
exp
A required claim that specifies when the token is expired and no longer valid.

Claim validation behavior in Confluent Platform version 7.7.0

sub
An subject identifier claim. This claim is required for Confluent Platform services but optional for Kafka listeners. To specify that a different claim act as the sub value, configure the oauthbearer.sub.claim.name property.
jti
An required token identifier claim.
iat
An required claim for the time at which the JWT was issued.
aud
Intended audience of the token and it typically includes the client ID of the application making the authentication request. This property is optional, but if aud is present in the token, the server checks it.
iss
A required claim it identifies the server that issued this token.
exp
A required claim that specifies when the token is expired and no longer valid.