CRED-2146: Add PAT auth support to Python 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 #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

---

Closing Note

This PR is being closed. PATs can be passed in using the existing OAuth (AuthZ) code path -- no new client library changes are needed. See the test program demonstrating this:

• test_program.py

[tausman]

Closing: PATs work via the existing OAuth (AuthZ) code path -- no new changes needed. See test_program.py.

[craSH]

There isn't really anywhere in the documentation (or PAT/SAT announcement blog post) that mention, explicitly, that you can use them with existing DD_APP_KEY environment variables and elsewhere that an Application Key would be used.

Could documentation be updated to explicitly mention this? It's a bit unusual in that it uses the same Application Key configuration surface, which otherwise needed a corresponding API key to work with before PATs/SATs were introduced.

I feel like a lot of home-grown code may also check for the presence of both the DD_API_KEY and DD_APP_KEY values, making it difficult to adapt existing code paths to this. I guess you can just set a bogus value for DD_API_KEY but that seems like it may invite issues down the road - is there any formal guidance on how clients should be using the new patterns?