Overview
Beginning April 30, 2026, if your Confluent Cloud organization uses an OAuth/OIDC identity provider that operates with common issuer URI and JWKS URI values — such as Google (https://accounts.google.com) — new identity pool filters under this identity provider must include a filter on the sub (subject) or aud (audience) claim. Creating or updating an identity pool will check for the filter to have a meaningful conditional on either sub or aud for the purpose of adding tenant validation on the token at authentication time.
If your identity provider’s issuer URI or JWKS URI contains unique tenant identifiers (e.g. a Microsoft Azure app registration, Okta OAuth application, or a self-hosted Keycloak instance with a unique issuer URL), this requirement does not apply — your authorization server already provides tenant isolation.
Background
Confluent Cloud allows configuring an external OAuth/OIDC identity provider (IdP) and define identity pools that map incoming tokens to identity pool principals in your organization. When Confluent Cloud validates a token, it verifies the token based keys fetched from the JWKS URI and matches claims in the token against the identity pool's filter expression.
A few identity providers — most notably Google — expose a global issuer URI and JWKS URI that is used by all tenants:
Provider |
Issuer URI |
JWKS URI |
|---|---|---|
|
|
Because these endpoints are shared, any valid token issued by that provider — regardless of which customer or workload it was originally issued for — could be validated against the same JWKS URI. If an identity pool filter does not narrow the match to your specific workload, a token issued to a different entity using the same provider could potentially match your pool.
What Claims Are Required and Why
The two claims that uniquely identify a token's intended target are:
aud (Audience) — Identifies the specific recipient the token was issued for.
sub (Subject) — Identifies the specific principal (user or service account) the token was issued to. Filtering on sub ensures only a known, specific identity can authenticate through a given pool.
Since these claims are set by the identity provider, the values cannot be spoofed by an unknown user who does not have access to your tenant or clients.
Including at least one of these in your identity pool filter ensures your pool only accepts tokens that were intentionally issued to your workload — not to any other entity that happens to use the same identity provider company.
Who Is Affected
This guidance applies to any Confluent Cloud customer who has configured an identity pool with an identity provider that uses a global authorization server with a generic issuer and JWKS URI. The most notable example of this is Google.
Google (
Issuer: https://accounts.google.com, JWKS URI: https://www.googleapis.com/oauth2/v3/certs) — used with GCP service accounts and workload identity, including the GCP JWT request flow supported by Apache Kafka clients (RFC 7523)Other multi-tenant SaaS identity providers where the issuer endpoint is shared across all of that provider's customers
If your issuer URI or JWKS URI contains unique tenant identifiers (e.g. a Microsoft Azure app registration, Okta OAuth application, or a self-hosted Keycloak instance with a unique issuer URL), this requirement does not apply — your authorization server already provides tenant isolation.
Required Action
This filter validation impacts new identity pool creations and updates, however, we strongly recommend reviewing your existing identity pool configurations to meet this standard for consistency and security. Each pool's filter expression must include a condition on at least sub or aud.
Steps:
In the Confluent Cloud Console, navigate to Accounts & access → Workload identities.
Navigate to your OAuth/OIDC identity provider using a generic URI (e.g.,
https://accounts.google.com)Review the identity pools filter expressions. Confirm it contains a meaningful condition on
claims.suborclaims.aud.If the filter does not include either claim, update it to add the appropriate restriction.
claims.aud == "https://www.company.com" && claims.sub == "112233445566778899"
A filter that matches only on generic claims such as claims.iss == "https://accounts.google.com" is insufficient on its own, since that condition matches tokens issued to any Google user or service account globally.