CRED-2150: Add OAuth/AuthZ bearer token support to Rust API client

[tausman]

PR Stack

API Client Libraries (closed)

All client libraries except Rust already support PATs via the existing OAuth/AuthZ code path. No new changes were needed.

• Go: CRED-2147: Add PAT auth support to Go API client datadog-api-client-go#3764 — CRED-2147 — PATs work via existing OAuth code path
• Python: CRED-2146: Add PAT auth support to Python API client datadog-api-client-python#3243 — CRED-2146 — PATs work via existing OAuth code path
• TypeScript: CRED-2148: Add PAT auth support to TypeScript API client datadog-api-client-typescript#3588 — CRED-2148 — PATs work via existing OAuth code path
• TypeScript v2: CRED-2148: Add PAT auth support to TypeScript v2 API client datadog-api-client-typescript#3610 — CRED-2148 — PATs work via existing OAuth code path
• Java: CRED-2149: Add PAT auth support to Java API client datadog-api-client-java#3555 — CRED-2149 — PATs work via existing OAuth code path
• Ruby: CRED-2151: Add PAT auth support to Ruby API client datadog-api-client-ruby#3058 — CRED-2151 — PATs work via existing OAuth code path

Rust: The Rust client generator does not support OAuth/AuthZ, so PATs cannot be used through the client library today. When OAuth/AuthZ support is added to the Rust generator in the future (#1438 has the approach), PATs will work automatically.

OpenAPI Spec Changes

• https://github.com/DataDog/datadog-api-spec/pull/5164 — CRED-2275: Add PAT/SAT management API endpoints

---

Why

All other Datadog API client libraries (Go, Python, TypeScript, Java, Ruby) support the AuthZ OAuth2 security scheme defined in the OpenAPI spec, which sends Authorization: Bearer <token>. The Rust client generator templates only handled type: apiKey schemes and silently skipped type: oauth2 (AuthZ). This PR adds OAuth2/AuthZ bearer token support to bring the Rust client to parity with other clients.

Commit structure

1. CRED-2150: Add OAuth/AuthZ bearer token support - templates — Template changes + tests (review this commit)
2. CRED-2150: Regenerated client code from templates — Generated code (137 files, can skip review)

Summary of changes

• Configuration struct: Added access_token: Option<String> field and set_access_token() method, matching the pattern in Go (ContextAccessToken) and Python (Configuration.access_token)
• api.j2 template: For endpoints that list AuthZ (type oauth2) in their security schemes, generated code now checks access_token first. If set, sends Authorization: Bearer <token>. Otherwise falls back to API key auth (DD-API-KEY + DD-APPLICATION-KEY)
• configuration.j2 template: Added access_token field, setter, and initialization
• Integration tests: tests/oauth_auth_test.rs verifying the public API

How it works

let mut configuration = datadog::Configuration::new();
configuration.set_access_token("your-oauth-token-or-pat".to_string());
let api = UsersAPI::with_config(configuration);
// Endpoints with AuthZ will send: Authorization: Bearer your-oauth-token-or-pat
// Endpoints without AuthZ still use DD-API-KEY + DD-APPLICATION-KEY

Test plan

• Integration tests pass (cargo test --test oauth_auth_test)
• Generated code compiles (cargo check)
• Live verification against staging using PAT via set_access_token() — 200 OK, users returned
• Endpoints WITHOUT AuthZ (e.g., v1 Authentication) do NOT generate bearer code
• Endpoints WITH AuthZ (e.g., v2 Users) correctly generate if/else bearer vs apiKey logic

[tausman]

Closing: Adding OAuth/AuthZ support to the Rust client is the right long-term approach for built-in PAT support, but we are not doing this work right now. When OAuth/AuthZ is implemented in the Rust generator in the future, PATs will work automatically (as they already do in Go, Python, TypeScript, Java, and Ruby).