@mathismeadows/roamer-device-auth 1.2.1 → 1.3.0

package/package.json

@@ -1,9 +1,9 @@
 {
   "name": "@mathismeadows/roamer-device-auth",
-  "version": "1.2.1",
+  "version": "1.3.0",
   "private": false,
   "type": "module",
-  "description": "AUTH-14/AUTH-25: 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 against Cloudflare Access Managed OAuth instead.",
+  "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).",
   "bin": {
     "roamer-device-auth": "./roamer-device-auth.mjs"
   },

package/roamer-device-auth.mjs

@@ -2,17 +2,19 @@
 // Roamer MCP — server-mediated device authorization flow (AUTH-25), used only for
 // Safari-default clients since AUTH-14's 2026-08-25 revival. Non-Safari clients (and any
 // OS where Safari isn't an option, e.g. Windows/Linux) instead use a standard direct
-// loopback-redirect flow against Cloudflare Access Managed OAuth — see
+// loopback-redirect flow against RoamerMcp's own OAuth authorization server — see
 // getValidTokensLoopback() below — removing the device-code confirmation screen AUTH-25's
 // prior unified design imposed on every client, Safari or not.
 //
 // Why Safari still needs device-code: Safari's HTTPS-Only Mode unconditionally blocks the
 // loopback flow's plain http:// callback (WebKitErrorDomain:305, confirmed live
-// 2026-08-20), and Cloudflare Access's Managed OAuth has no device-code grant of its own
-// (confirmed live the same day — device authentication is not supported for MCP portals
-// per Cloudflare's own docs), so RoamerMcp's server implements the RFC 8628 shape itself
-// for that case, brokering a real Authorization Code + PKCE exchange with Cloudflare
-// server-to-server. detectDefaultBrowser() below decides which path a given machine takes.
+// 2026-08-20), so RoamerMcp's server implements the RFC 8628 shape itself for that case.
+// AUTH-38: as of 2026-08-27 the actual login step this brokers is against Entra directly
+// (RoamerMcp's server acting as an OAuth client of its own AS, then handing this process a
+// RoamerMcp-signed token pair) — previously it brokered against Cloudflare Access Managed
+// OAuth server-to-server instead, back when Cloudflare was the token issuer for every
+// RoamerMcp client, not just this one. detectDefaultBrowser() below decides which path
+// (this one or the loopback one) a given machine takes.
 //
 // AUTH-24: this is the publishable source for the @mathismeadows/roamer-device-auth npm
 // package — roamer-bridge.sh (here and in roamer-mcp-plugin) invokes the published,
@@ -111,41 +113,50 @@ function clearCachedTokens() {
   return writeFile(CACHE_FILE, "{}", { mode: 0o600 }).catch(() => {});
 }
 
-// AUTH-14: loopback-flow cache — a brand-new file, never previously used by any other
-// mechanism, so (unlike CACHE_FILE above) there's no prior-format collision risk to guard
-// against with a version stamp.
-async function readLoopbackTokens() {
+// AUTH-14/AUTH-38: loopback-flow caches, stamped with the authorization server URL they were
+// obtained against. Not just a version stamp (like CACHE_VERSION above) — a real issuer
+// comparison, so ANY future AS migration self-invalidates these automatically, not just this
+// one. Confirmed live 2026-08-27 this gap is real, not theoretical: AUTH-35 retargeted RoamerMcp's
+// discovery documents from Cloudflare Access Managed OAuth to RoamerMcp's own AS, and a client_id
+// or token cached from before that change would otherwise be silently carried forward and
+// presented to a completely different issuer with no invalidation at all.
+async function readLoopbackTokens(issuerUrl) {
   try {
     const tokens = JSON.parse(await readFile(LOOPBACK_TOKENS_FILE, "utf8"));
+    if (tokens?.issuerUrl !== issuerUrl) return null;
     return tokens?.access_token ? tokens : null;
   } catch {
     return null;
   }
 }
 
-async function writeLoopbackTokens(tokens) {
+async function writeLoopbackTokens(tokens, issuerUrl) {
   await mkdir(CACHE_DIR, { recursive: true, mode: 0o700 });
-  await writeFile(LOOPBACK_TOKENS_FILE, JSON.stringify(tokens, null, 2), { mode: 0o600 });
+  const stamped = { ...tokens, issuerUrl };
+  await writeFile(LOOPBACK_TOKENS_FILE, JSON.stringify(stamped, null, 2), { mode: 0o600 });
 }
 
 function clearLoopbackTokens() {
   return writeFile(LOOPBACK_TOKENS_FILE, "{}", { mode: 0o600 }).catch(() => {});
 }
 
-// DCR'd client registration is reused across runs — Cloudflare's registration_endpoint has
-// no reason to be hit on every single sign-in, only the first one (or after a reset).
-async function readLoopbackClientInfo() {
+// DCR'd client registration is reused across runs — the authorization server's
+// registration_endpoint has no reason to be hit on every single sign-in, only the first one (or
+// after a reset, or after an issuer change per this function's own issuerUrl check above).
+async function readLoopbackClientInfo(issuerUrl) {
   try {
     const info = JSON.parse(await readFile(LOOPBACK_CLIENT_FILE, "utf8"));
+    if (info?.issuerUrl !== issuerUrl) return null;
     return info?.client_id ? info : null;
   } catch {
     return null;
   }
 }
 
-async function writeLoopbackClientInfo(info) {
+async function writeLoopbackClientInfo(info, issuerUrl) {
   await mkdir(CACHE_DIR, { recursive: true, mode: 0o700 });
-  await writeFile(LOOPBACK_CLIENT_FILE, JSON.stringify(info, null, 2), { mode: 0o600 });
+  const stamped = { ...info, issuerUrl };
+  await writeFile(LOOPBACK_CLIENT_FILE, JSON.stringify(stamped, null, 2), { mode: 0o600 });
 }
 
 // AUTH-14: which auth mechanism a given machine uses. Safari-default clients (macOS only —
@@ -176,7 +187,7 @@ async function detectDefaultBrowser() {
 
 // Claude Code (or any MCP host) may kill this process and respawn a fresh one if it doesn't
 // see a stdio handshake within its own connect timeout — and the interactive device flow
-// (dialog -> browser -> Cloudflare's consent screen -> poll) routinely takes longer than a
+// (dialog -> browser -> Entra's consent screen -> poll) routinely takes longer than a
 // human can click through inside a short timeout. Without persisting the in-progress flow,
 // every respawn called /oauth/device/start again, which mints a BRAND NEW device_code/
 // user_code — the user would see a different code every single retry, forever, with no
@@ -341,8 +352,8 @@ async function doGetValidTokens(forceRefresh) {
   }
 }
 
-// AUTH-14: fixed, well-known port for the loopback callback — Cloudflare's DCR'd client
-// registration is persisted and reused across every future sign-in (see
+// AUTH-14: fixed, well-known port for the loopback callback — the authorization server's DCR'd
+// client registration is persisted and reused across every future sign-in (see
 // readLoopbackClientInfo), so the redirect_uri baked into that registration has to stay
 // stable across runs. A fixed port sidesteps re-registering on every single interactive
 // sign-in; the tradeoff (a port-in-use conflict is possible, if rare) is the same one this
@@ -413,21 +424,26 @@ function getValidTokensLoopback(forceRefresh = false) {
 }
 
 async function doGetValidTokensLoopback(forceRefresh) {
-  let tokens = forceRefresh ? null : await readLoopbackTokens();
+  // AUTH-38: discovery has to run before any cached token/client is trusted, not after — a
+  // cached-but-not-yet-expired token from a prior authorization server would otherwise be
+  // returned early below without ever learning the issuer changed underneath it.
+  const serverInfo = await discoverLoopbackServerInfo();
+  const issuerUrl = serverInfo.authorizationServerUrl.toString();
+
+  let tokens = forceRefresh ? null : await readLoopbackTokens(issuerUrl);
 
   if (!forceRefresh && tokens?.access_token && !expiresSoon(tokens)) {
     return tokens;
   }
 
-  const serverInfo = await discoverLoopbackServerInfo();
-  let clientInformation = await readLoopbackClientInfo();
+  let clientInformation = await readLoopbackClientInfo(issuerUrl);
 
   if (!forceRefresh && tokens?.refresh_token && clientInformation) {
     try {
       log("Refreshing cached token...");
       const fresh = await refreshLoopbackTokens(tokens.refresh_token, serverInfo, clientInformation);
       tokens = { ...fresh, obtained_at: Date.now() };
-      await writeLoopbackTokens(tokens);
+      await writeLoopbackTokens(tokens, issuerUrl);
       return tokens;
     } catch (err) {
       log(`Refresh failed (${err.message}), falling back to a fresh sign-in.`);
@@ -437,7 +453,7 @@ async function doGetValidTokensLoopback(forceRefresh) {
   if (forceRefresh) await clearLoopbackTokens();
 
   if (!clientInformation) {
-    log("Registering as a new OAuth client with Cloudflare...");
+    log("Registering as a new OAuth client...");
     clientInformation = await registerClient(serverInfo.authorizationServerUrl, {
       metadata: serverInfo.authorizationServerMetadata,
       clientMetadata: {
@@ -448,21 +464,20 @@ async function doGetValidTokensLoopback(forceRefresh) {
         token_endpoint_auth_method: "none",
       },
     });
-    await writeLoopbackClientInfo(clientInformation);
+    await writeLoopbackClientInfo(clientInformation, 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
+  // doesn't bind or read a resource parameter at all, so sending one now would be dead weight,
+  // not a compatibility need — same reasoning as OAuthAuthorizationServerService's own Entra-
+  // facing hop never sending one (see that class's doc comment for the Entra-side reason, a
+  // different one: including it there triggers AADSTS9010010).
   const { authorizationUrl, codeVerifier } = await startAuthorization(serverInfo.authorizationServerUrl, {
     metadata: serverInfo.authorizationServerMetadata,
     clientInformation,
     redirectUrl: LOOPBACK_REDIRECT_URI,
-    // RFC 8707: Cloudflare's authorization endpoint rejects the request without this
-    // (invalid_target / "No resource parameter found") — the exact same requirement
-    // DeviceFlowService.cs already hit and fixed server-side for the device-code path
-    // (confirmed live 2026-08-21) and just reconfirmed live here 2026-08-26. Only the
-    // authorization step needs it; DeviceFlowService.cs's token/refresh calls don't
-    // reference it at all, so exchangeAuthorization/refreshAuthorization below don't either.
-    resource: new URL(ROAMER_MCP_URL),
   });
 
   const server = createServer();
@@ -502,7 +517,7 @@ async function doGetValidTokensLoopback(forceRefresh) {
     redirectUri: LOOPBACK_REDIRECT_URI,
   });
   tokens = { ...fresh, obtained_at: Date.now() };
-  await writeLoopbackTokens(tokens);
+  await writeLoopbackTokens(tokens, issuerUrl);
   log("Sign-in complete.");
   return tokens;
 }
@@ -662,4 +677,12 @@ if (isMainModule) {
   });
 }
 
-export { respondWithSignInError, forwardLine, detectDefaultBrowser };
+export {
+  respondWithSignInError,
+  forwardLine,
+  detectDefaultBrowser,
+  readLoopbackTokens,
+  writeLoopbackTokens,
+  readLoopbackClientInfo,
+  writeLoopbackClientInfo,
+};