Using the OpenTelemetry Authenticator Extension

Authentication is a critical piece of any telemetry pipeline — whether you’re receiving data from trusted agents or exporting telemetry to third-party services. The OpenTelemetry Collector (or OTel collector) supports this via the OpenTelemetry authenticator extension, which allows you to plug in authentication logic for both receivers and exporters.

In this post, we’ll explore:

✅ What the authenticator extension does

✅ How to configure it for receivers (e.g., to authenticate OTLP data)

✅ How to use it with exporters (e.g., to send data securely)

✅ Example configs you can copy and adapt

Let’s dig in.

🔐 What Is the OpenTelemetry Authenticator Extension?

The authenticator is a type of extension that allows you to apply custom authentication logic to telemetry data entering or leaving the OpenTelemetry Collector.

• With Receivers: You can validate incoming requests (e.g., bearer token, mTLS, etc.)
• With Exporters: You can apply authentication headers or credentials when sending data to an external system

The authenticator itself doesn’t enforce any one method — instead, it provides a plug-in interface so you can register implementations that support your use case (e.g., basicauth, bearer, oidc, etc.)

⚙️ Example 1: Use Authenticator on a Receiver (OTLP + Basicauth)

Imagine you’re running an OTLP receiver and want to accept telemetry only from agents that provide a valid username and password.

🧱 Step 1: Define the OpenTelemetry Authenticator Extension

extensions:
  basicauth/server:
    htpasswd:
      inline: |
        agent:s3cr3t

⚠️ This example uses basicauth for simplicity, but in production, use HTTPS and rotate secrets.

You can also supply the credentials in a htpasswd.file as described in the basic authenticator docs here.

🧱 Step 2: Enable the OTLP Receiver with Authenticator

receivers:
  otlp:
    protocols:
      http:
        auth:
          authenticator: basicauth/server

🧱 Step 3: Hook into the Service

service:
  extensions: [basicauth/server]
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [debug]

With this config, any agent sending OTLP over HTTP must supply a valid basic auth header. Unauthorized requests will be rejected with 401.

🧱 Step 4: Complete Sample Collector Config and Running the Collector

Here is a complete collector config you can use (e.g. save as otel-config.yaml)

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
        auth:
          authenticator: basicauth/server

extensions:
  basicauth/server:
    htpasswd:
      inline: |
        agent:s3cr3t

exporters:
  debug:
    verbosity: detailed

service:
  extensions: [basicauth/server]
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [debug]

And then you can run the collector in Docker like:

docker run -v ./otel-config.yaml:/etc/otelcol-contrib/config.yaml -p 4318:4318 otel/opentelemetry-collector-contrib:0.123.0

🌐 Example 2: Use OpenTelemetry Authenticator Extension on an Exporter (OTLP + Header Injection)

Now let’s flip the scenario: you’re exporting data from your collector to another collector or observability backend that requires authentication (e.g., a bearer token or API key in the header). A good example of this is sending via OTLP (http) to the Grafana Cloud backend.

🧱 Step 1: Configure the Authenticator for Export

extensions:
  basicauth/client:
    username: collector
    password: export-secret

You can also use OIDC, AWS SigV4, or other supported authenticators depending on your backend.

🧱 Step 2: Apply to an Exporter

exporters:
  otlphttp:
    endpoint: <https://your.observability.vendor/ingest>
    auth:
      authenticator: basicauth/client

🧱 Step 3: Register in the Service

service:
  extensions: [basicauth/client]
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [otlphttp]

Now your exporter will send each request with a Basicauth header.

🛠 Supported Types For the OpenTelemetry Authenticator Extension

The core OTel Collector and contrib repo support various auth types, depending on what extensions you load:

• basicauth – Simple username/password
• bearertoken – Static bearer token in headers
• oidc – OAuth2/OpenID Connect (including token refresh)
• aws – AWS SigV4 signing (for exporters like awsxray)

Each one plugs into the authenticator interface and can be used with receivers or exporters.

🧪 Testing Authentication

You can test your receiver setup with curl and find an example trace.json file to use here:

curl -X POST <http://localhost:4318/v1/traces> \
  -H "Authorization: Basic $(echo -n 'agent:s3cr3t' | base64)" \
  -H "Content-Type: application/json" \
  -d @trace.json

You should see a span appear in your terminal where you’re running your collector if authentication is successful, and a message from curl like {"partialSuccess":{}}% or a message like Unauthorized if auth fails.

You can validate outbound headers from exporters using a proxy like mitmproxy.

🧠 Wrapping Up

The OpenTelemetry authenticator extension is a powerful mechanism for securing telemetry flow in and out of your collector. Whether you’re enforcing incoming auth or securely sending data upstream, it’s a flexible way to apply your org’s access controls.

Need help configuring authentication across your OTel collectors and exporters?

We work with platform teams to build secure, scalable observability pipelines. Get in touch →

Back

Share