Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#577 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

@Dumindu-Kanchana já está trabalhando nisso.

Desde 30/9/2026.

  • #578 de @Dumindu-Kanchana — aberto

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
78/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
typescript
Domínio
authentication

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.
Linguagem predominante
TypeScript
Estrelas
18
Forks
67
Merge médio
3h 40min
PRs com merge (30d)
15

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de asgardeo/javascript

Todas as issues de asgardeo/javascript

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.