fix(oauth): add client id to token exchange#2805
fix(oauth): add client id to token exchange#2805davidkl97 wants to merge 1 commit intogoogle:mainfrom
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
There was a problem hiding this comment.
Summary of Changes
Hello @davidkl97, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request refines the OAuth2 token exchange mechanism by incorporating the client ID into the request. This modification is crucial for aligning with the OAuth 2.0 specification, thereby improving the security and standard compliance of the authentication flow.
Highlights
- OAuth Compliance: The pull request adds the
client_idparameter to the token exchange request, ensuring adherence to RFC 6749, section 4.1.3.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
b1f4d1e to
3fda17f
Compare
|
Response from ADK Triaging Agent Hello @davidkl97, thank you for creating this PR! This PR is a bug fix, could you please associate the github issue with this PR? If there is no existing issue, could you please create one? In addition, could you please provide logs or screenshot after the fix is applied? This information will help reviewers to review your PR more efficiently. Thanks! |
There was a problem hiding this comment.
Code Review
This pull request correctly adds the client_id to the OAuth2 token exchange request, which is a good practice for ensuring compatibility with various OAuth2 providers. The change is sound. I've included one minor suggestion to improve code formatting by removing an unnecessary blank line.
3fda17f to
00539fa
Compare
00539fa to
3366dce
Compare
|
Hey @Jacksunwei , can you review this please? |
|
@davidkl97 Thanks for creating this PR! Have you verified it works as expected end to end? |
|
Hey @xuanyang15 , yes it works as expected once client id is passed |
Merge #2805 fixes #2806 add client id to token request, adhering to [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.3) Co-authored-by: Xuan Yang <xygoogle@google.com> COPYBARA_INTEGRATE_REVIEW=#2805 from davidkl97:fix/oauth-exchange-token 3366dce PiperOrigin-RevId: 840369113
|
Thank you @davidkl97 for your contribution! 🎉 Your changes have been successfully imported and merged via Copybara in commit f273517. Closing this PR as the changes are now in the main branch. |
Authlib's OAuth2Session already handles client_id placement for all token_endpoint_auth_method values (client_secret_basic puts it in the Authorization header, client_secret_post and none put it in the body). Passing client_id as a kwarg to fetch_token causes it to be added to the POST body unconditionally via prepare_token_request, in addition to whatever the auth method does. This breaks providers like Slack that infer auth method from the presence of client_id in the body, and causes duplicate client_id for client_secret_post. Partially reverts f273517 (PR google#2805), which was based on a misreading of RFC 6749 §4.1.3 — client_id in the body is only REQUIRED "if the client is not authenticating with the authorization server as described in Section 3.2.1." Made-with: Cursor
Authlib's OAuth2Session already handles client_id placement for all token_endpoint_auth_method values (client_secret_basic puts it in the Authorization header, client_secret_post and none put it in the body). Passing client_id as a kwarg to fetch_token causes it to be added to the POST body unconditionally via prepare_token_request, in addition to whatever the auth method does. This breaks providers like Slack that infer auth method from the presence of client_id in the body, and causes duplicate client_id for client_secret_post. Partially reverts f273517 (PR google#2805), which was based on a misreading of RFC 6749 §4.1.3 — client_id in the body is only REQUIRED "if the client is not authenticating with the authorization server as described in Section 3.2.1." Made-with: Cursor
Authlib's OAuth2Session already handles client_id placement for all token_endpoint_auth_method values (client_secret_basic puts it in the Authorization header, client_secret_post and none put it in the body). Passing client_id as a kwarg to fetch_token causes it to be added to the POST body unconditionally via prepare_token_request, in addition to whatever the auth method does. This breaks providers like Slack that infer auth method from the presence of client_id in the body, and causes duplicate client_id for client_secret_post. Partially reverts f273517 (PR google#2805), which was based on a misreading of RFC 6749 §4.1.3 — client_id in the body is only REQUIRED "if the client is not authenticating with the authorization server as described in Section 3.2.1." Made-with: Cursor
fixes #2806
add client id to token request, adhering to RFC 6749