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

@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?

@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.

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.

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.

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.)