feat(otel-collector): add OIDC bearer token auth for the OTLP receiver

[arj22]

Summary

Adds oidcauthextension as an alternative to the existing static bearer token auth (config.standalone.auth.yaml / OTLP_AUTH_TOKEN) in standalone mode.

Motivation: the current standalone-mode auth option is a single long-lived shared secret (OTLP_AUTH_TOKEN) checked against every request. That's a reasonable default for small/trusted deployments, but doesn't scale well to large or less-trusted fleets of OTLP producers -- a single leaked token compromises every sender indefinitely, since there's no way to revoke or scope it to one client. This PR adds OIDC-based bearer token validation as an opt-in alternative: producers present a JWT (Authorization: Bearer <token>) issued by any OIDC-compatible provider, and the collector validates it against that provider's published JWKS (fetched from {issuer_url}/.well-known/openid-configuration), checking iss/aud/exp. This lets self-hosters issue short-lived, per-client tokens instead of one static secret, using whatever identity provider/token-minting approach they already have -- the collector side just needs issuer_url and audience.

Changes:

• packages/otel-collector/builder-config.yaml: add oidcauthextension to the OCB build manifest (same version pin pattern as the existing bearertokenauthextension entry)
• docker/otel-collector/config.standalone.oidc.yaml: new file, mirrors config.standalone.auth.yaml's structure -- OIDC_ISSUER_URL/OIDC_AUDIENCE env vars configure the extension on both OTLP protocols (grpc + http)
• docker/otel-collector/entrypoint.sh: include the new config file when OIDC_ISSUER_URL is set; otherwise fall back to OTLP_AUTH_TOKEN as before. The two are treated as mutually exclusive (both configure the same receiver's auth.authenticator, so enabling both would just make config-load order decide the winner, which seemed worth avoiding)
• docker/otel-collector/Dockerfile: copy the new config into both the dev and prod image stages, alongside the existing standalone config files

Validation: ran a local docker build -f docker/otel-collector/Dockerfile --target ocb-builder . and confirmed the extension compiles into otelcol-hyperdx and appears in components output (oidc | github.com/open-telemetry/opentelemetry-collector-contrib/extension/oidcauthextension). I have not run this against a live OIDC provider end-to-end, and there's no automated test yet -- happy to add one if there's a preferred pattern for extension-config integration tests in this repo, or to adjust the approach (e.g. if a CUSTOM_OTELCOL_CONFIG_FILE-based approach is preferred over a new baked-in standalone config).

How to test on Vercel preview

N/A -- non-UI change (otel-collector only).

References

• Related: Add other login options besides basic auth (OIDC) #1140, Implement SSO for the HyperDX UI login #1316 (OIDC/SSO for the HyperDX UI login -- different feature area from this PR, which is about OTLP ingestion auth, not UI auth. Linking for context since both mention OIDC.)

---

This PR was drafted with Claude Code assistance (I saw your CONTRIBUTING.md's AI-Assisted Development section and the .claude/ tooling in-repo, so figured that was fair game) and reviewed/tested by me before opening -- happy to adjust the approach based on maintainer feedback.

🤖 Generated with Claude Code

[changeset-bot]

🦋 Changeset detected

Latest commit: 251d9e9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@hyperdx/otel-collector	Minor
@hyperdx/api	Minor
@hyperdx/app	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@arj22 is attempting to deploy a commit to the HyperDX Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Summary

The PR adds opt-in OIDC bearer-token validation to the standalone OTLP receiver while preserving static-token authentication as the fallback.

• Compiles oidcauthextension into the custom collector distribution.
• Adds and packages a standalone OIDC configuration for both OTLP transports.
• Selects OIDC authentication when issuer and audience are configured and fails fast when the audience is missing.
• Adds the required collector package changeset.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the missing-audience path now exits with a clear error, and the required changeset is present.

Important Files Changed

Filename	Overview
docker/otel-collector/entrypoint.sh	Selects OIDC ahead of static-token authentication and now explicitly rejects a missing audience before collector startup.
docker/otel-collector/config.standalone.oidc.yaml	Defines the OIDC authenticator and attaches it to both standalone OTLP transports.
packages/otel-collector/builder-config.yaml	Adds the published OIDC authentication extension to the custom collector build.
docker/otel-collector/Dockerfile	Packages the new OIDC configuration in both development and production collector images.
.changeset/add-oidc-otlp-auth.md	Records the user-facing collector authentication feature as a minor package change.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Env{Standalone auth environment}
  OIDC[OIDC issuer and audience]
  Static[Static OTLP auth token]
  Open[No receiver authentication]
  Config[Load standalone OIDC config]
  Bearer[Load standalone bearer-token config]
  Receiver[OTLP receiver: gRPC and HTTP]
  Provider[OIDC discovery and JWKS]
  Pipeline[HyperDX ingest pipelines]

  Env -->|OIDC_ISSUER_URL set| OIDC
  Env -->|Otherwise OTLP_AUTH_TOKEN set| Static
  Env -->|Neither set| Open
  OIDC --> Config
  Config --> Receiver
  Config --> Provider
  Static --> Bearer
  Bearer --> Receiver
  Open --> Receiver
  Receiver --> Pipeline

Loading

_{Reviews (3): Last reviewed commit: "Merge branch 'main' into add-oidc-otlp-a..." | Re-trigger Greptile}

[arj22]

@pulpdrew This looks stuck on pending workflow approval, not code — Docker Build/Main/Knip/PR Triage are all action_required (first-time-contributor gate), so the test suite hasn't actually run yet.

Mind approving the pending runs when you get a chance?