@mathismeadows/roamer-device-auth 1.5.8 → 1.5.10

package/package.json

@@ -1,12 +1,12 @@
 {
   "name": "@mathismeadows/roamer-device-auth",
-  "version": "1.5.8",
+  "version": "1.5.10",
   "private": false,
   "mcpName": "com.mathismeadows/roamer-mcp",
   "type": "module",
   "description": "AUTH-14/AUTH-25/AUTH-38: stdio<->HTTP MCP proxy for Roamer MCP with two auth mechanisms, chosen per-machine by default-browser detection. Safari-default machines use a server-mediated device authorization flow (AUTH-25) since Safari's HTTPS-Only Mode blocks a loopback redirect; every other machine uses a standard direct loopback redirect instead. Both authenticate against RoamerMcp's own OAuth authorization server (AUTH-38). AUTH-54/55/57/58: sessions are cached per (client, identity) pair, with explicit login/logout/status subcommands to switch or inspect which identity a client is using.",
   "bin": {
-    "roamer-device-auth": "./roamer-device-auth.mjs"
+    "roamer-device-auth": "roamer-device-auth.mjs"
   },
   "main": "./roamer-device-auth.mjs",
   "files": [

package/roamer-device-auth.mjs

@@ -462,6 +462,18 @@ async function writeLoopbackClientInfo(clientSlug, info, issuerUrl) {
   await writeFile(path, JSON.stringify(stamped, null, 2), { mode: 0o600 });
 }
 
+// Found live 2026-09-11: a client_id registered before the authorization server started
+// persisting/validating DCR registrations (e.g. before AUTH-42) can be cached here
+// indefinitely under the SAME issuerUrl — readLoopbackClientInfo's own issuer check above
+// only invalidates on an actual AS migration, not on a server-side tightening like AUTH-42
+// that invalidates old client_ids without changing the issuer at all. Paired with the
+// retry-once-with-a-fresh-registration logic in doGetValidTokensLoopback below.
+function clearLoopbackClientInfo(clientSlug) {
+  const path = cacheFilePath("roamer_loopback_client", clientSlug);
+  if (!path) return Promise.resolve();
+  return unlink(path).catch(() => {});
+}
+
 // AUTH-14: which auth mechanism a given machine uses. Safari-default clients (macOS only —
 // Safari isn't an option elsewhere) take the device-code path above, since Safari's
 // HTTPS-Only Mode blocks the loopback callback outright. Everything else, including every
@@ -756,6 +768,27 @@ function waitForLoopbackCallback(server) {
   });
 }
 
+// Found live 2026-09-11: when RoamerMcp's own /oauth/authorize rejects a client_id (e.g.
+// invalid_client for one registered before AUTH-42 started persisting/validating
+// registrations), it renders that error directly in the browser per AUTH-42's own "never
+// redirect on failure" security rule — the browser never comes back to this loopback
+// server at all. Without this timeout, callbackPromise above would then hang forever with
+// zero visibility, since nothing else ever completes or fails. This is the one signal this
+// process can observe for that entire failure class (a rejected authorize response looks
+// identical, from here, to the user simply never finishing the browser flow).
+const LOOPBACK_AUTHORIZE_TIMEOUT_MS = 120_000;
+
+function withLoopbackTimeout(promise) {
+  let timer;
+  const timeout = new Promise((_, reject) => {
+    timer = setTimeout(
+      () => reject(new Error("LOOPBACK_AUTHORIZE_TIMEOUT: no callback received")),
+      LOOPBACK_AUTHORIZE_TIMEOUT_MS,
+    );
+  });
+  return Promise.race([promise, timeout]).finally(() => clearTimeout(timer));
+}
+
 // AUTH-14: must follow the real WWW-Authenticate resource_metadata hint from a live 401,
 // not RoamerMcp's own default .well-known/oauth-protected-resource document, which still
 // mirrors Entra directly and would send a standards-compliant client to the wrong
@@ -812,6 +845,7 @@ async function doGetValidTokensLoopback(clientSlug, forceRefresh, forceFreshLogi
   // it identifies this app instance to the authorization server, not the person using it, so
   // every identity signing in from the same client-slug reuses the same registered client_id.
   let clientInformation = await readLoopbackClientInfo(clientSlug, issuerUrl);
+  const clientInformationWasCached = Boolean(clientInformation);
 
   if (!forceRefresh && !forceFreshLogin && tokens?.refresh_token && clientInformation) {
     try {
@@ -828,23 +862,49 @@ async function doGetValidTokensLoopback(clientSlug, forceRefresh, forceFreshLogi
   if (forceRefresh && identityKey) await clearLoopbackTokens(clientSlug, identityKey);
 
   if (!clientInformation) {
-    log("Registering as a new OAuth client...");
-    // AUTH-51: the registered client_name carries the connecting client's own identity when
-    // known, so a future server-side session list/audit view could actually tell clients
-    // apart instead of seeing the same generic name for every stdio-bridge user.
-    clientInformation = await registerClient(serverInfo.authorizationServerUrl, {
-      metadata: serverInfo.authorizationServerMetadata,
-      clientMetadata: {
-        client_name: clientSlug ? `Roamer MCP (stdio bridge — ${clientSlug})` : "Roamer MCP (stdio bridge)",
-        redirect_uris: [LOOPBACK_REDIRECT_URI],
-        grant_types: ["authorization_code", "refresh_token"],
-        response_types: ["code"],
-        token_endpoint_auth_method: "none",
-      },
-    });
-    await writeLoopbackClientInfo(clientSlug, clientInformation, issuerUrl);
+    clientInformation = await registerFreshLoopbackClient(serverInfo, clientSlug, issuerUrl);
   }
 
+  // Found live 2026-09-11: a cached client_id can be rejected at authorize-time (invalid_client)
+  // for reasons that have nothing to do with the current issuer — e.g. AUTH-42 requiring
+  // registrations to be persisted/validated, applied after this client_id was already cached.
+  // performLoopbackInteractiveSignIn can't distinguish that from the user simply never
+  // finishing the browser flow (see LOOPBACK_AUTHORIZE_TIMEOUT_MS's own comment), so on ANY
+  // failure here, if the client_id in use came from cache rather than a fresh registration
+  // this same call already did, assume it might be stale, clear it, register a brand new one,
+  // and retry the interactive flow exactly once — never a second time, so a genuinely broken
+  // server or a real user cancellation still surfaces as an error instead of looping.
+  try {
+    return await performLoopbackInteractiveSignIn(serverInfo, clientInformation, clientSlug, issuerUrl);
+  } catch (err) {
+    if (!clientInformationWasCached) throw err;
+    log(`Sign-in failed with a cached OAuth client (${err.message}). Re-registering and retrying once...`);
+    await clearLoopbackClientInfo(clientSlug);
+    clientInformation = await registerFreshLoopbackClient(serverInfo, clientSlug, issuerUrl);
+    return await performLoopbackInteractiveSignIn(serverInfo, clientInformation, clientSlug, issuerUrl);
+  }
+}
+
+async function registerFreshLoopbackClient(serverInfo, clientSlug, issuerUrl) {
+  log("Registering as a new OAuth client...");
+  // AUTH-51: the registered client_name carries the connecting client's own identity when
+  // known, so a future server-side session list/audit view could actually tell clients
+  // apart instead of seeing the same generic name for every stdio-bridge user.
+  const clientInformation = await registerClient(serverInfo.authorizationServerUrl, {
+    metadata: serverInfo.authorizationServerMetadata,
+    clientMetadata: {
+      client_name: clientSlug ? `Roamer MCP (stdio bridge — ${clientSlug})` : "Roamer MCP (stdio bridge)",
+      redirect_uris: [LOOPBACK_REDIRECT_URI],
+      grant_types: ["authorization_code", "refresh_token"],
+      response_types: ["code"],
+      token_endpoint_auth_method: "none",
+    },
+  });
+  await writeLoopbackClientInfo(clientSlug, clientInformation, issuerUrl);
+  return clientInformation;
+}
+
+async function performLoopbackInteractiveSignIn(serverInfo, clientInformation, clientSlug, issuerUrl) {
   log("Starting sign-in...");
   // AUTH-38: no `resource` parameter — that was a Cloudflare Access Managed OAuth-specific
   // requirement (RFC 8707; it rejected the request without one). RoamerMcp's own /oauth/authorize
@@ -882,7 +942,7 @@ async function doGetValidTokensLoopback(clientSlug, forceRefresh, forceFreshLogi
 
   let authorizationCode;
   try {
-    authorizationCode = await callbackPromise;
+    authorizationCode = await withLoopbackTimeout(callbackPromise);
   } finally {
     server.close();
   }
@@ -894,7 +954,7 @@ async function doGetValidTokensLoopback(clientSlug, forceRefresh, forceFreshLogi
     codeVerifier,
     redirectUri: LOOPBACK_REDIRECT_URI,
   });
-  tokens = { ...fresh, obtained_at: Date.now() };
+  const tokens = { ...fresh, obtained_at: Date.now() };
   const freshIdentityKey = identityKeyFromTokens(tokens);
   const freshLabel = identityLabelFromTokens(tokens);
   await writeLoopbackTokens(clientSlug, tokens, issuerUrl, freshIdentityKey);
@@ -1384,6 +1444,7 @@ export {
   writeLoopbackTokens,
   readLoopbackClientInfo,
   writeLoopbackClientInfo,
+  clearLoopbackClientInfo,
   // AUTH-54/55/57/58
   cacheFilePath,
   identityKeyFromTokens,