Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#577 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Dumindu-Kanchana ci sta già lavorando.

Dal 30/9/2026.

  • #578 di @Dumindu-Kanchana — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
78/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
authentication

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
TypeScript
Stelle
18
Fork
67
Merge medio
3h 40m
PR unite (30g)
15

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di asgardeo/javascript

Tutte le issue di asgardeo/javascript

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.