Best Practices for OAuth-OIDC Identity Providers on Confluent Cloud

When you use Confluent OAuth, your OAuth identity provider is responsible for identity management. This offers you flexibility for managing your identities, but it is only as secure as the protections enforced on the identity provider itself.

Precautions about using the same identity provider across multiple organizations

If you use the same OAuth identity provider (with the same Issuer URI and JWKS URI) across multiple organizations that you own, any access tokens issued by your OAuth identity provider can be used across all of the organizations. Use a pool filter to ensure that the the access tokens are used for specific operations or purposes within a particular organization.

Use identity pool filters

Leverage identity pool filters for all of your identity pools. Use claims, such as aud, scp, or others, to restrict access for specific purposes or operations.

Verify network access to the JWKS URI regularly

If your identity provider is behind a firewall, you should verify network access from Confluent Cloud to your identity provider using the public IP addresses at least every three months to ensure that Confluent Cloud can access your identity provider JWKS endpoint over the internet. For details on verifying network access, see Verify network access to the JWKS URI.

Use claims to restrict access to specific organizations

If you need to restrict the usage of a token to a single organization, you must configure your identity provider as needed to supply the appropriately restricted access tokens.

For example, you can configure your identity provider to issue tokens with specific claim values (aud, scp, or others). These claims can be configured as filters in a particular organization’s pool. Even though the token signature is valid for all of your organizations, the token claims only pass validation to an organization that contains an identity pool with a filter that matches the token’s claims.

Don’t rely on keeping pool IDs hidden

Pool IDs are not considered sensitive information. Instead, you should use pool filters to restrict access to specific pools without exposing sensitive access information.

For example, suppose you have two organizations, orgA and orgB:

  • The administrator for orgA is security conscious and creates pools with restrictive pool filters and role bindings.
  • The administrator for orgB is not security-conscious and creates an identity pool with a permissive pool filter.

Because the access token from their single identity provider would work across both organizations (orgA and orgB), a user with valid, but restrictive access to orgA could then get elevated access to orgB, simply by discovering orgB’s pool IDs, which are explicitly non-sensitive. This access should be restricted by applying appropriately restrictive filters on the pools of orgB.