fix: reuse the popup for the interactive retry — no more blocked second window / 'Open new window' dialog

[jeswr]

Problem

DPoPTokenProvider always tries prompt=none first, so a fresh login is: silent attempt → login_required → interactive retry. AuthorizationCodeFlow closed the popup on every callback message, so the retry had to open() a new window — outside the original click's (already consumed) user activation. Popup blockers stop that, stranding the user in the "User interaction needed to launch authorization code flow in new window → Open new window" dialog on every first login. This is the "unnecessary accepting of prompts to redirect" users report.

Change

Keep the popup open when the callback message carries one of the OIDC "user must interact" errors (login_required / interaction_required / consent_required) — exactly the errors token providers retry interactively right away. The retry's open(uri, sameWindowName) then merely navigates the existing named window, which browsers always allow without user activation.

Result: the user sees one popup that goes from the silent bounce straight to the IdP login page — no blocked window, no interstitial dialog, no extra click.

A code response or a terminal error (e.g. access_denied when the user denies consent) still closes the window exactly as before; cancel/abort paths are unchanged.

Verification

• npm run build (tsc): clean.
• The repo has no DOM test setup, so this is verified live: a Playwright-driven login (Chrome popup blocker enabled, --disable-popup-blocking removed) against a deployed pod manager + Solid-OIDC broker (https://app.solid-test.jeswr.org). Before: silent popup closes → second window needed. After: one popup, prompt=none bounce navigates in place to the Keycloak login, flow completes with zero interstitial dialogs.

Future work (out of scope here): running the prompt=none attempt in a hidden iframe would remove the popup flash for purely silent re-auth; that needs a callback.html contract change (parent vs opener), so it is left for a separate discussion.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR updates the AuthorizationCodeFlow popup lifecycle so that when a silent prompt=none attempt returns an OIDC “user must interact” error (login_required, interaction_required, consent_required), the popup is kept open. This enables the subsequent interactive retry to reuse (navigate) the same named popup window, avoiding popup-blocker failures that occur when trying to open a second window without user activation.

Changes:

• Keep the authorization popup open on OIDC “interaction needed” error callbacks to allow interactive retry to navigate the existing named window.
• Add a helper (needsInteraction) to detect the relevant OIDC error responses from the callback URL.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jeswr]

Fixed in 1ce81c1: the listener now ignores any message whose source is not the authorization popup, and removes itself on the matching message instead of using { once: true }.

[langsamu]

@jeswr,

1. I have taken the second commit to main in a3c618c because it's independently good.
2. I like the improved, seamless UX. But I don't like that the UI element duplicates functionality from the token provider. Both now check for the error messages. I'd like to think a bit more about this.
3. Is it correct to start with prompt=none? I see differences between the authorization servers: Some require interaction, others don't. Maybe I was doing something wrong in the journey?

[jeswr]

@langsamu thanks — answering your three points, with behavioural evidence rather than guessing where it's a runtime question.

1. Taking the second commit to main (a3c618c). 👍 Agreed it stands alone; this PR is now just the popup-reuse change on top of it.

2. The UI element duplicating the token provider's error-message checks. This is a fair observation and I don't want to paper over it — it is genuine duplication. Both AuthorizationCodeFlow#needsInteraction (UI) and DPoPTokenProvider#authenticate (provider) independently classify the same three OIDC errors (login_required / interaction_required / consent_required). They do it for different reasons — the UI needs to decide whether to keep the popup open for the retry, the provider needs to decide whether to retry at all — but the predicate is the same, so a server that returned a fourth "interaction" error, or a change to the set, would need editing in two places. I agree it's worth thinking about before merge rather than rushing it; happy to factor the predicate into one shared, exported helper (e.g. in the provider, consumed by the UI) if you'd like that direction. I've left this unresolved deliberately — flagging it as a real design point, not closing it.

3. "Is it correct to start with prompt=none? Some servers require interaction, others don't."

Short answer: yes, starting with prompt=none is correct — it's the OIDC "silent authentication" pattern (OIDC Core §3.1.2.1). The differences you saw are expected and handled, and they come from session state at the AS, not from a server doing something wrong.

prompt=none means "authenticate me only if you can do it without any UI":

• If the user already has an active session at that AS → the AS returns a code with no interaction (silent success).
• If they don't → the AS returns one of login_required / interaction_required / consent_required, and the code retries interactively (dropping prompt, or sending prompt=consent when we're opting into offline_access). See DPoPTokenProvider.ts#authenticate (the validateAuthResponse catch block) and AuthorizationCodeFlow#needsInteraction.

So "some require interaction, others don't" is the same server behaving differently depending on whether you already had a session — which is exactly the win prompt=none buys us (no popup when one isn't needed).

Evidence (Playwright, on branch threads/evidence, runs credential-free):

I sent an unauthenticated prompt=none authorization request — same params the provider sends (PKCE/S256, scope=openid webid) — to three real servers and captured what each returns. Test: prompt-none.spec.ts; helper: oidc.ts.

Server	cold prompt=none (no session) →
solidcommunity.net (CSS / oidc-provider)	error=interaction_required — "An account cookie is required."
login.inrupt.com (ESS)	error=interaction_required — "Interaction required to proceed"
idp.solid-test.jeswr.org (the broker)	error=login_required — "End-User authentication is required"

All three decline the silent attempt, and the only difference is which of the three error strings they use (CSS/ESS say interaction_required, the broker says login_required) — both already in the retry set, so the flow handles all three. Run output: 6 passed (3 skipped).

Two accuracy caveats I want to be straight about:

• The "warm" half — an existing AS session making prompt=none return a code silently — I could not test autonomously, because it needs a real interactive login (credentials I don't have here). It's left as a documented skipped test in warm-session.spec.ts with the scaffolding in place, rather than faked. That's the half that produces the "doesn't require interaction" outcome you saw, so if your journey hit a server that didn't prompt, you most likely already had a session there.
• One incidental finding: both CSS and the broker reject prompt=none without PKCE with invalid_request ("policy requires PKCE"), before getting to the interaction check — see probe-prompt-none.out vs probe-prompt-none-pkce.out. The real client always sends PKCE when code_challenge_methods_supported is present, so this doesn't affect us; just noting it so the error you observe is reproducible.

Also recorded the discovery metadata the provider keys its behaviour off (refresh_token grant, offline_access scope, PKCE, DPoP algs) for all three in discovery.spec.ts.

[jeswr]

prompt=none evidence — expanded across the full Solid server matrix

Following up on the earlier 3-server evidence: I broadened the probe to every distinct known Solid server codebase the reactive-fetch app could be pointed at (it's server-agnostic — the user types their issuer at runtime, so the target set is "all known Solid IdPs"). All probes are credential-free (dynamic public-client registration + an unauthenticated prompt=none authorize request, PKCE/S256, scope=openid webid), mirroring DPoPTokenProvider#authenticate's silent first attempt. Observed 2026-06-12.

Tests pushed to threads/evidence @ 6eeb86e — new table-driven specs prompt-none-matrix.spec.ts + discovery-matrix.spec.ts, driven by the codebase-tagged MATRIX in oidc.ts. They tolerate unreachable hosts (skip with a recorded reason) and pass: 25 passed, 9 skipped.

Server	Codebase	prompt=none result	In retry set?	PKCE	offline_access	DPoP	refresh_token
solidcommunity.net	CSS	interaction_required (303→cb)	✅	S256	✅	✅ ES256…	✅
solidweb.me	CSS	interaction_required (303→cb)	✅	S256	✅	✅ ES256…	✅
localhost (local)	CSS (full-control)	interaction_required (303→cb)	✅	S256	✅	✅ ES256…	✅
teamid.live	Pivot (CSS remix)	interaction_required (303→cb)	✅	S256	✅	✅ ES256…	✅
login.inrupt.com	ESS (Inrupt)	interaction_required (303→cb)	✅	plain/S256	✅	✅ ES256	✅
idp.solid-test.jeswr.org	broker (Keycloak)	login_required (303→cb)	✅	S256	✅	✅ ES256…	✅
solidweb.org	NSS	HTML login page (200, no OIDC error)	❌	❌ none	✅	❌ none	✅
datapod.igrant.io	NSS	HTML login page (200, no OIDC error)	❌	❌ none	✅	❌ none	✅
trinpod.us	Trinpod (TwinPod-Server)	HTML login page /gmxLogin (200, no OIDC error)	❌	plain/S256	❌	✅ ES256/RS256	✅
trinpod.eu	Trinpod (TwinPod-Server)	HTML login page /gmxLogin (200, no OIDC error)	❌	plain/S256	❌	✅ ES256/RS256	✅
use.id	CSS	unreachable (DNS NXDOMAIN)	—	—	—	—	—
inrupt.net	NSS	/.well-known/openid-configuration → 404 (no discovery doc)	—	—	—	—	—
Manas (Rust)	Manas	no reachable public OIDC endpoint — unverified	—	—	—	—	—
PHP Solid Server	pdsinterop	no public hosted instance — unverified	—	—	—	—	—

Codebases covered (live): CSS, Pivot, ESS, NSS, Trinpod — plus a local full-control CSS as a self-hosted control.
Recorded as unreachable / unverified: use.id (DNS), inrupt.net (NSS, no discovery doc — it 303s to start.inrupt.com), Manas, pdsinterop PHP (no public IdP — docs/self-host only).

So: is it correct to start with prompt=none?

For the OIDC-provider-based servers (CSS, Pivot, ESS, our broker) — yes, unambiguously. Every one declines the session-less silent attempt with one of {login_required, interaction_required, consent_required} (the exact set AuthorizationCodeFlow#needsInteraction retries on); the only per-server difference is which of the three strings, which the library already handles. The "differences between authorization servers" you observed are expected and absorbed. The warm-session half (existing AS session → silent code) still needs an interactive login and remains the documented skip in warm-session.spec.ts.

⚠️ One finding worth flagging (accuracy over closure)

NSS and Trinpod do not honour prompt=none. Instead of redirecting back to the callback with an OIDC error, they 302 to their own HTML login page and return HTTP 200 with text/html — there is no error= parameter to classify at all. So the library's retry path, which keys off the three error strings on the callback redirect, never fires for these two codebases. In the popup flow this happens to degrade gracefully (the user just sees a login form in the still-open popup, which is the intended end state), so it isn't broken today. But it means the silent-attempt → classify-error contract genuinely does not hold for ~2 of the live codebases, and the classifier can't distinguish "AS is asking the user to log in via HTML" from "AS errored opaquely."

Possible small hardening, if we want to be precise: when the prompt=none attempt lands on a non-callback HTML response (rather than a callback redirect carrying an error), treat that as an implicit interaction_required and fall through to the interactive retry — instead of relying solely on the three error strings. Not urgent (popup degrades fine), but it would make the retry classification correct for NSS/Trinpod rather than incidentally-fine. Happy to open a separate issue if you'd like.

(Also minor, for the record: NSS advertises no PKCE and no DPoP in discovery, and Trinpod advertises no offline_access and only client_secret_basic token auth — so the refresh-token / DPoP paths from #11/#12 won't engage on those codebases regardless.)