OAuthBearer

SASL/OAUTHBEARER is a standard Kafka SASL mechanism (defined by RFC 7628) that authenticates to the Kafka brokers with a short-lived OAuth 2.0 bearer token instead of a static username and password.

Unlike PLAIN and SCRAM, OAUTHBEARER tokens are dynamic, so they are always sourced from a guard rather than a static config value. Configure the kafka client binding's options.authorization with the oauthbearer mechanism, and point token at the guard's extracted credentials:

Static or Pre-Issued Token

An inline guard can hold a static or environment-sourced token, useful when a token is issued out of band, for example by an internal auth service:

name: example
guards:
  authn_kafka:
    type: inline
    options:
      credentials: ${{env.KAFKA_SASL_TOKEN}}
bindings:
  south_kafka_client:
    type: kafka
    kind: client
    options:
      servers:
        - ${{env.KAFKA_BOOTSTRAP_SERVER}}
      authorization:
        authn_kafka:
          credentials:
            mechanism: oauthbearer
            token: "{credentials}"
    exit: south_tcp_client
  south_tcp_client:
    type: tcp
    kind: client

Amazon MSK IAM Auth

An aws-iam guard signs an Amazon MSK IAM authentication token from an AWS IAM role, refreshing it every challenge seconds, so Kafka Gateway authenticates to MSK without any broker-side username or password:

name: example
guards:
  msk_iam_auth:
    type: aws-iam
    kind: msk
    options:
      region: us-east-1
      credentials:
        source: default
      challenge: 900
bindings:
  south_kafka_client:
    type: kafka
    kind: client
    options:
      servers:
        - ${{env.KAFKA_BOOTSTRAP_SERVER}}
      authorization:
        msk_iam_auth:
          credentials:
            mechanism: oauthbearer
            token: "{credentials}"
    exit: south_tcp_client
  south_tcp_client:
    type: tcp
    kind: client

The guard authenticates first, and its extracted credentials are substituted into the {credentials} placeholder to build the token sent to the broker.

Try the example

The http.kafka.oneway.oauthbearer example in the Zilla repository runs the static-token variant end to end as a full HTTP-to-Kafka pipeline, including a JWKS server the Kafka broker validates the token against.

See SASL for the PLAIN and SCRAM mechanisms, and TLS to also encrypt the connection.