feat(auth): in-MCP auth login — complete the OAuth flow from inside the session, secure backend only #89

New issue

Closed

opened 2026-07-15 14:46:02 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-15 14:46:02 +00:00

(Migrated from codeberg.org)

Problem

An unauthed session has no sanctioned remedy from inside the harness. Today the agent hits not configured - run 'madtea auth login' first (loudly at connect once #88 lands), and the only fix is dropping to a terminal to run the interactive login. And the tempting agent-side workaround is now an explicit anti-goal — decision (2026-07-15): an agent must never cross outside the launch pwd and use auth tokens it finds in other checkouts (see the companion boundary-enforcement issue). The launch scope is the credential boundary, so authenticating that scope, in-session is the only correct remedy short of relaunching.

Ask

An MCP-surface login that completes the existing OAuth flow for the launch-scope forge (likely madt_auth_login, or an action on the auth noun; gated domain is fine):

Initiate: the tool starts the OAuth flow (the client-id-per-forge machinery already exists) and returns the authorize/device URL to open in a browser — the agent's role is only to relay the URL.
Complete: a poll/confirm step (second action or same call waiting with progress notifications, which reset the idle timeout per the #10 matrix) receives the token server-side and stores it via the secure backend only. ADR 0013 applies with no MCP escape: the MCP surface never accepts an insecure-storage override — refusal with the actionable error, same as promptToken.
Confirm: result reports the authed identity (whoami-equivalent: user + host + storage backend), never token material.

Hard constraints:

Token paste is out. The MCP spec forbids requesting sensitive information via elicitation, and a pasted token would transit the model conversation. Elicitation (client support confirmed in #10) MAY be used for non-secret choices only (which forge host, scope confirmation).
No token material in any tool result, log line, or progress notification.
Server instructions/banner are fixed at initialize, so the session banner won't refresh after login — the completion result must state clearly that API tools are now live (and #88's per-call error should stop firing immediately, since resolution is per-call).

Acceptance

From an unauthed session: initiate → URL returned → I complete in browser → subsequent API-plane tool calls succeed with no server restart.
Storage lands in the secure backend; on a host with no backend the tool refuses with the ADR 0013 error (no plaintext path, no override param).
No secret string appears anywhere in the MCP transcript surface (tool results, notifications).

Refs #88 (connect-time warning that points here), #10 (elicitation/progress client-support matrix), the launch-scope credential-boundary issue (ruling that rules out token borrowing).

## Problem An unauthed session has no sanctioned remedy from inside the harness. Today the agent hits `not configured - run 'madtea auth login' first` (loudly at connect once #88 lands), and the only fix is dropping to a terminal to run the interactive login. And the tempting agent-side workaround is now an explicit anti-goal — decision (2026-07-15): **an agent must never cross outside the launch pwd and use auth tokens it finds in other checkouts** (see the companion boundary-enforcement issue). The launch scope is the credential boundary, so authenticating *that scope, in-session* is the only correct remedy short of relaunching. ## Ask An MCP-surface login that completes the existing OAuth flow for the launch-scope forge (likely `madt_auth_login`, or an action on the auth noun; gated domain is fine): 1. Initiate: the tool starts the OAuth flow (the client-id-per-forge machinery already exists) and returns the authorize/device URL to open in a browser — the agent's role is only to relay the URL. 2. Complete: a poll/confirm step (second action or same call waiting with progress notifications, which reset the idle timeout per the #10 matrix) receives the token server-side and stores it via the **secure backend only**. ADR 0013 applies with no MCP escape: the MCP surface never accepts an insecure-storage override — refusal with the actionable error, same as `promptToken`. 3. Confirm: result reports the authed identity (whoami-equivalent: user + host + storage backend), never token material. Hard constraints: - **Token paste is out.** The MCP spec forbids requesting sensitive information via elicitation, and a pasted token would transit the model conversation. Elicitation (client support confirmed in #10) MAY be used for non-secret choices only (which forge host, scope confirmation). - No token material in any tool result, log line, or progress notification. - Server instructions/banner are fixed at initialize, so the session banner won't refresh after login — the completion result must state clearly that API tools are now live (and #88's per-call error should stop firing immediately, since resolution is per-call). ## Acceptance - From an unauthed session: initiate → URL returned → I complete in browser → subsequent API-plane tool calls succeed with no server restart. - Storage lands in the secure backend; on a host with no backend the tool refuses with the ADR 0013 error (no plaintext path, no override param). - No secret string appears anywhere in the MCP transcript surface (tool results, notifications). Refs #88 (connect-time warning that points here), #10 (elicitation/progress client-support matrix), the launch-scope credential-boundary issue (ruling that rules out token borrowing).

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#89

No description provided.

Rows
Columns