signInSilently() always resolves false: getAuthorizeRequestUrlParams overwrites the "sign-in-silently" state with instance_<id>

Start in packages/javascript/src/utils/getAuthorizeRequestUrlParams.ts and trace getSignInUrl in packages/javascript/src/legacy/client.ts, then compare the silent-sign-in callers in main-thread-client.ts and web-worker-client.ts. Add or update a regression test for getSignInUrl({ prompt: 'none', state: 'sign-in-silently' }) with instance ID 0. Done means the generated state retains the silent marker and the relevant test suite passes.

Description

signInSilently() can never report success. The silent sign-in URL is built with
state: "sign-in-silently", but getAuthorizeRequestUrlParams replaces the caller's
state with instance_<instanceId> whenever an instance ID is present — and
getSignInUrl always passes one. The authorize request goes out with
state=instance_0_request_N, so the hidden iframe never recognises the IdP's
response as a silent sign-in, never posts the code to the parent, and the parent's
10 s timeout resolves false.

The override was introduced in 10ca5ed4 ("Refactor instance ID handling in authorization
flow and update state parameter format") and is still present on main (3487684).

Root cause

1. The silent sign-in URL asks for the silent state
   (main-thread-client.ts#L325-L330,
   same in web-worker-client.ts#L420-L426):

   _authenticationClient.getSignInUrl({ prompt: 'none', state: SILENT_SIGN_IN_STATE, ...additionalParams })
   

2. getSignInUrl always passes an instance ID
   (legacy/client.ts#L288):
   instanceId: this.getInstanceId().toString() — "0" for the default instance, which is truthy.
3. getAuthorizeRequestUrlParams then discards the caller's state
   (getAuthorizeRequestUrlParams.ts#L101-L121).
   state is skipped in the customParams loop (L103), and the only branch that would
   use it is unreachable when instanceId is set:

   if (options.instanceId) {
     customStateValue = AUTH_INSTANCE_PREFIX + options.instanceId;          // always taken
   } else if (customParams) {
     customStateValue = customParams[OIDCRequestConstants.Params.STATE]?.toString() ?? ''; // never reached
   }
   

4. In the iframe, the response is only treated as a silent sign-in if the state contains the marker
   (session-management-helper.ts#L178,
   spa-utils.ts#L152-L156):
   state.includes(SILENT_SIGN_IN_STATE) is false, so nothing is posted to the parent, and the parent
   resolves false on its timeout
   (authentication-helper.ts#L574).

The check-session prompt-none request passes state: STATE the same way
(session-management-helper.ts#L158),
so syncSession looks affected by the same override (not verified at runtime).

Expected

The authorize request carries a state containing sign-in-silently; the iframe posts
the code to the parent, the parent exchanges it, and the promise resolves with the user.

Actual

Captured with the Chrome DevTools Protocol:

• The /oauth2/authorize?prompt=none request carries the IdP session cookies
  (commonAuthId, opbs, SameSite=None) — none excluded, so this is not
  third-party-cookie blocking.
• The IdP answers 302 Location: <afterSignInUrl>?code=…&session_state=…&state=instance_0_request_1.
• The iframe loads afterSignInUrl with that code. Nothing is posted to the parent,
  the parent makes no token request, and signInSilently() resolves false ~10 s later.

Side effect: because afterSignInUrl is the app itself, the app boots inside the iframe
and shares the tab's sessionStorage. Its AsgardeoProvider then either

• sees isSignedIn() true and ignores the code (nothing is renewed), or
• runs a normal signIn() and exchanges the code itself (token request initiated from
  signIn), so the session is renewed — while the parent still gets false.

An app that treats false as "session lost" therefore asks the user to sign in again
even when it now holds valid tokens.

Suggested fix

Keep both parts instead of letting the instance prefix replace the caller's state:

const instanceState = options.instanceId ? AUTH_INSTANCE_PREFIX + options.instanceId : '';
const callerState = customParams?.[OIDCRequestConstants.Params.STATE]?.toString() ?? '';
const customStateValue = [instanceState, callerState].filter(Boolean).join('_');

This yields e.g. instance_0_sign-in-silently_request_0, which still satisfies
hasCalledForThisInstanceInUrl (state=instance_<id>_[^&]+) and
state.includes(SILENT_SIGN_IN_STATE) / state.includes(STATE).
A regression test for getSignInUrl({ prompt: 'none', state: 'sign-in-silently' })
with instance ID 0 asserting the marker survives would cover it.

Related: #527 (no on-demand refresh-token use when the access token has expired).

Steps to Reproduce

1. React SPA with <AsgardeoProvider>, default config (sessionStorage, PKCE on),
   afterSignInUrl set to the app's own origin (e.g. http://localhost:3000).
2. Sign in normally.
3. Call signInSilently() from useAsgardeo() and inspect the network.
4. Observe the authorize request's state=instance_0_request_N (no sign-in-silently),
   the IdP's 302 with a code into the hidden iframe, and the promise resolving false
   after ~10 s.

Please select the area the issue is related to

@asgardeo/javascript, @asgardeo/browser, @asgardeo/react

Version

@asgardeo/react 0.25.14 (@asgardeo/browser 0.7.17, @asgardeo/javascript 0.23.6); also reproduced on @asgardeo/react 0.22.4 (@asgardeo/browser 0.6.6, @asgardeo/javascript 0.18.0). Present on main at 3487684.

Environment Details (with versions)

macOS 26.6.2, Chrome 154.0.8037.93, React 19.2.3.

Reporter Checklist

• I have searched the existing issues and this is not a duplicate.
• I have provided all the necessary information.
• I have tested the issue on the latest version of the package.