Add Authentication RFD #330
Conversation
benbrandt
left a comment
benbrandt
left a comment
There was a problem hiding this comment.
Another option might be:
- provide two new capabilities on the client
- Request text
- Request to open link
- The agent returns auth methods as they do now
- User picks one of the options
- Within the authenticate method, the agent asks the client for a key and optionally a link to open to get said key or device code
The reason I bring this up is usually for the oauth flows there are specific links and maybe the need to spin up a local http server (at least for codex this is the case) to handle the redirect post-auth. So I don't know that the agent can upfront provide the urls without entering in to a specific auth flow.
Maybe what i am proposing is too generic and opens pandora's box though....
| "name": "OpenAI api key", | ||
| "description": "Provide your key", | ||
| "type": "envVar", | ||
| "varName": "OPEN_AI_KEY", |
There was a problem hiding this comment.
Question: is it too late to add the env var since the process has already started?
Could we maybe just model this as a request for a text field that the user pastes the token into? and then the agent would store it somewhere like it usually does?
Or maybe you had an idea here that I am missing?
There was a problem hiding this comment.
In this case we'll have to restart the process indeed. If the agent is ok with just accepting a key in JsonRpc call, then it should declare 3. option — Provided key
There was a problem hiding this comment.
Do you think this method should rather be included in #289 ? i.e. static information known before startup?
But I guess we want to allow the user to choose? So by choosing this we'd restart the agent for them but at least they could choose if that is what they want from the options?
There was a problem hiding this comment.
But I guess we want to allow the user to choose? So by choosing this we'd restart the agent for them but at least they could choose if that is what they want from the options?
yes, that was my idea
|
@benbrandt why I think approach with agent requesting a text input won't work as good as we want it to : |
|
Ack ACP and MCP are different specs (editor-agent vs. tool integration), but MCP's elicitation (URL mode) provides prior art for out-of-band credential handling that avoids LLM/agent exposure. It pauses for browser input without touching the protocol flow. Is this relevant to the design discussion for how to handle sensitive info exchange in ACP? https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation |
|
Yeah I think MCP elicitation is not a bad way to approach it for two reasons:
I have some quibbles with the api design... but I don't know that it is worth changing for reason 1 above. The interesting thing will be that this elicitation would come outside the context of a session. Which I believe you brought up yesterday @anna239 in our call: we may want a very explicit stage for this, because if we allow for elicitation, we'd need to know if it should show up within a session feed or somewhere else. |
|
I agree that URL-elicitation mechanism would work well for the oauth scenario, let me update rfd with this approach |
|
Added part about MCP-like elicitation mechanism for oauth, @codefromthecrypt thank you so much for pointing this out to me. |
| "name": "OpenAI api key", | ||
| "description": "Provide your key", | ||
| "type": "startParam", | ||
| "paramName": "OPEN_AI_KEY", |
There was a problem hiding this comment.
Could this also be handled if we supported the full elicitation options?
There was a problem hiding this comment.
I think it's more like env var, so this one also requires restart
| "id": 3, | ||
| "method": "elicitation/create", | ||
| "params": { | ||
| "authenticateRequestId": "123", |
There was a problem hiding this comment.
is this some kind of metadata? I guess what is special about this vs a normal elicitation? (other than perhaps the context)
There was a problem hiding this comment.
As I mentioned before I think it's important for UX purposes to connect agent's request for elicitation with the particular authentication request. Maybe we can make it more general and allow providing requestId, so that it would also work for the case of elicitations that are connected to other user's actions?
Define a way for an agent to declare different ways to authenticate, this will allow clients to present better UX to users.