fix(auth): populate oauthScope/myId in getSignerFromOAuthToken, clarify authMiddleware flow#734
Conversation
…fy authMiddleware flow When a PKCE Bearer token resolves a signer via getSignerFromOAuthToken, populate oauthScope and myId directly on the context so that authMiddleware doesn't need a redundant second PKCE token lookup. Also restructures authMiddleware with explicit priority comments and moves signature headers to lowest priority after Bearer-based auth flows. Adds TestOAuthMe_WithApiSecret to verify /me works when the PKCE token belongs to a developer app that also has an api_secret in api_keys. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 28321821 | Triggered | Generic High Entropy Secret | b6a5be1 | api/v1_oauth_test.go | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
There was a problem hiding this comment.
Pull request overview
This PR refines OAuth/PKCE authentication handling by ensuring PKCE-derived context (scope + user id) is populated during signer resolution, and by clarifying/reordering authMiddleware’s authentication method precedence to avoid redundant token lookups.
Changes:
- Populate
oauthScopeandmyIdingetSignerFromOAuthTokenso downstream handlers (e.g./v1/me) don’t require a second PKCE token lookup. - Restructure
authMiddlewarewith explicit precedence ordering and move signature-header auth to lowest priority after Bearer-based flows. - Add a regression test covering
/v1/mewhen a PKCE token’s client also has anapi_secretinapi_keys.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| api/v1_oauth_test.go | Adds regression test for /v1/me with PKCE token + api_secret present. |
| api/request_helpers.go | Ensures PKCE OAuth token signer resolution also sets oauthScope/myId on the request context. |
| api/auth_middleware.go | Reorders/clarifies auth resolution flow and makes signature headers lowest priority. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Summary
getSignerFromOAuthToken, populateoauthScopeandmyIddirectly on the context — previouslyauthMiddlewaredid a redundant second PKCE token lookup to fill these inauthMiddlewarewith explicit priority comments, and moves signature headers to lowest priority (after Bearer-based flows)TestOAuthMe_WithApiSecretto verify/meworks when the PKCE token belongs to a developer app that also has anapi_secretregistered inapi_keysTest plan
go test ./api/... -run TestOAuthMe— all 6 pass🤖 Generated with Claude Code