Enable OAuth on remaining API+App Key endpoints: 100% client-side coverage - #832
Merged
platinummonkey merged 2 commits intoSep 16, 2026
Conversation
The server caught up on both surfaces: fleet-api now serves /api/unstable/fleet with RouteAuthn including ValidOAuthAccessToken (dd-source#93561), and every Continuous Profiler endpoint on prof-gateway accepts OAuth (the remaining exclusions predated prof-gateway's OAuth rollout). Remove the five stale entries. Add GET /api/v2/validate_keys as an indefinitely-excluded entry: the endpoint validates the exact API+App key pair the caller holds, so OAuth would defeat its purpose. It becomes the canonical example exercising the both-keys fallback path in tests.
State the policy as general (API + App Key endpoints should also accept OAuth) without claiming the list is known-complete — the server-side rollout is still in progress. Both remaining entries are exact matches, so drop the trailing-/ prefix-match branch, which no entry can exercise. Replace the 15 per-family no-fallback tests (~300 lines of point-in-time comments) with a single table-equality test that fails on any deliberate or incidental change to the exception list, plus an exact-match test.
srosenthal-dd
changed the title
srosenthal-dd
marked this pull request as ready for review
September 16, 2026 18:36
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
platinummonkey
approved these changes
Sep 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This gets pup to 100% OAuth support(*) on the client side! 🚀
With few exceptions, the general rule is that any API which accepts API+App Key should also accept OAuth. Submitting telemetry (POST events) and similar are exceptions where they'll only allow API keys (with no App Key).
I'm working on finishing up server-side OAuth support - we're at 90+% with a plan to get to ~100% in the next couple of weeks.
Changes
The
OAUTH_EXCLUDED_ENDPOINTStable shrinks from 6 entries to 2: onlyPOST /api/v1/events(API-key-only intake) andGET /api/v2/validate_keys(indefinite server-side exemption; validates the API+App key pair the caller holds) remain.Notes
Behavior change:
pup apiand raw helpers now send the OAuth bearer for fleet unstable GETs and profiling paths instead of forcing API+App key fallback. Typed commands already did.