Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#577 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@Dumindu-Kanchana ya está trabajando en esto.

Desde el 30/9/2026.

  • #578 de @Dumindu-Kanchana — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
78/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
authentication

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
TypeScript
Estrellas
18
Forks
67
Merge medio
3 h 40 min
PR fusionados (30 d)
15

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de asgardeo/javascript

Todos los issues de asgardeo/javascript

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.