# Azure Authenticator Extension | Status | | | ------------- |-----------| | Stability | [beta] | | Distributions | [contrib] | | Issues | [](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues?q=is%3Aopen+is%3Aissue+label%3Aextension%2Fazureauth) [](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues?q=is%3Aclosed+is%3Aissue+label%3Aextension%2Fazureauth) | | Code coverage | [](https://app.codecov.io/gh/open-telemetry/opentelemetry-collector-contrib/tree/main/?components%5B0%5D=extension_azureauth&displayType=list) | | [Code Owners](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/CONTRIBUTING.md#becoming-a-code-owner) | [@constanca-m](https://www.github.com/constanca-m), [@dyl10s](https://www.github.com/dyl10s) | [beta]: https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/component-stability.md#beta [contrib]: https://github.com/open-telemetry/opentelemetry-collector-releases/tree/main/distributions/otelcol-contrib This extension can be used in two directions: - **In exporters (outbound):** attaches the collector's Azure identity as a bearer token to outgoing requests. - **In receivers (inbound):** when wired as an `extensionauth.Server` (for example, `protocols.http.auth.authenticator: azure_auth`), validates incoming bearer tokens as OIDC JWTs against a configured issuer and audience. Requires the `server` block (see [Inbound JWT validation](#inbound-jwt-validation)). > **Security advisory:** Versions `v0.124.0` through `v0.150.0` contain a server-side authentication bypass (`GHSA-pjv4-3c63-699f`). Do not use `azure_auth` under a receiver `auth:` block on those versions. The outbound exporter usage is unaffected. Additionally, the extension also implements `azcore.TokenCredential` so that Azure components can get the token by running the function `GetToken`. If the component supports HTTP client, then this should not be necessary, as the token will be placed in the authorization header. It supports 4 different types of authentication: - Managed identity for Azure resources - Workload identity for Kubernetes - Service principal with either a client secret or client certificate path for non Azure. - And the default credentials. This is not recommended for production. ## Examples ### Managed identity User based: ```yaml extensions: azure_auth: managed_identity: client_id: ${CLIENT_ID} ``` System based (leave `client_id` field empty): ```yaml extensions: azure_auth: managed_identity: ``` ### Workload identity ```yaml extensions: azure_auth: workload_identity: client_id: ${CLIENT_ID} federated_token_file: ${FILE} tenant_id: ${TENANT_ID} ``` ### Service principal With client secret: ```yaml extensions: azure_auth: service_principal: client_id: ${CLIENT_ID} tenant_id: ${TENANT_ID} client_secret: ${CLIENT_SECRET} ``` With client certificate path: ```yaml extensions: azure_auth: service_principal: client_id: ${CLIENT_ID} tenant_id: ${TENANT_ID} client_certificate_path: ${CLIENT_CERTIFICATE_PATH} ``` ### Default authentication Not recommended for production. ```yaml extensions: azure_auth: use_default: true ``` ### With custom scopes You can set custom scopes if the audience required in the token does not match the host you are trying to reach. This is useful for Azure Monitor Workspaces since the workspace hostname is specific to your instance whereas the audience required is `https://monitor.azure.com/.default` ```yaml: extensions: azure_auth: scopes: - https://monitor.azure.com/.default ``` ### Inbound JWT validation The `server` block is required only in this specific case: - A server protocol's `auth.authenticator` points at `azure_auth` (for example, `receivers.otlp.protocols.http.auth.authenticator: azure_auth`). This is the only path that validates inbound bearer tokens. Do not set `server` in any other case, including: - Exporter-only usage. - A receiver that loads `azure_auth` as an `azcore.TokenCredential` to call Azure APIs (for example, a receiver reading from Azure Blob Storage). That path does not validate incoming tokens, so `server` has no effect. When set, incoming bearer tokens are validated as OIDC JWTs: signature against the issuer's JWKS, plus `iss`, `aud`, `exp`, and `nbf`. The audience is pinned from config and never derived from request headers. Requests are rejected on any missing config or failed check. Fields: - `server.issuer_url`: Entra ID tenant discovery URL (`https://login.microsoftonline.com//v2.0`). - `server.audience`: `aud` value required in valid tokens (for example, `api://collector-ingest`). ```yaml extensions: azure_auth: use_default: true server: issuer_url: https://login.microsoftonline.com/${TENANT_ID}/v2.0 audience: api://collector-ingest receivers: otlp: protocols: http: endpoint: 0.0.0.0:4318 auth: authenticator: azure_auth ```