Replies: 1 comment
-
I concur with @arryon, this appears to be not-right. @seanzhou1023 WDYT? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I have a concern around the security of the default ADK handling of tool authentication and would appreciate some validation on this.
The ADK app exposes the /run_sse endpoint where we can interact with the runner's
run_async
loop.Tool authentication is arranged in such a way that we indicate a tool's required authentication and ADK handles the token exchange.
In case there is no active token, the special
adk_request_credential
flow is triggered, and in case of Oauth2 this sometimes requires the client to prompt the user with an interactive authorization flow.The documentation also describes this process: https://google.github.io/adk-docs/tools/authentication/#2-handling-the-interactive-oauthoidc-flow-client-side
My concern is around how this interactive flow is documented and handled by default. If we inspect the payload that gets generated inside
/run_sse
, anEvent
is broadcasted that has a full serialization of the raw oauth credentials includingclient_id
andclient_secret
.This feels like bad practice to advertise as method to prompt an external client to try and authenticate a user in an external application. The documentation states "Agent Client application interacts with ADK's fastapi server via /run or /run_sse endpoint. While ADK's fastapi server could be setup on the same server or different server as Agent Client application".
In auth, we should never expose client secrets to any external client we cannot trust, and front-end clients are among those. I think the documentation on how to handle the tool authentication in any client is not informing the user of the security risk, and we should pro-actively design a method that does not expose client secrets via
/run_sse
. One such approach might be to add a dedicated endpoint to the ADK FastAPI app that initiates the sign in, sends only the authorization URL to the client, and facilitates requesting new tokens from the third party oauth endpoint, instead of expecting the client to provide updated credentials.Example payload JSON:
Let me know what you think please! Cheers
Beta Was this translation helpful? Give feedback.
All reactions