Token exchange not completing after OAuth redirect in mashlib/browser context

[melvincarvalho]

Summary

solid-client-authn-browser receives the OAuth authorization code after redirect but does not complete the token exchange. The library stores the codeVerifier in localStorage but never exchanges the code for tokens.

Environment

• solid-client-authn-browser: 2.3.0 (via solid-logic 4.0.1)
• Browser: Chrome 131
• Server: Custom Solid server with oidc-provider
• Context: Mashlib data browser

Steps to Reproduce

1. Load mashlib in browser
2. Click "Sign In"
3. Complete login at IdP
4. Redirect back to app with ?code=...&state=... in URL

Expected Behavior

Library should:

1. Detect the auth code in URL
2. Retrieve codeVerifier from localStorage (solidClientAuthenticationUser:* keys)
3. POST to token endpoint with PKCE exchange
4. Store tokens and set session.info.isLoggedIn = true

Actual Behavior

• Auth code is in URL
• codeVerifier exists in localStorage under solidClientAuthenticationUser:* key
• Token exchange never happens
• session.info.isLoggedIn remains false
• No network request to /idp/token endpoint

localStorage State After Redirect

{
  "solidClientAuthenticationUser:default": {
    "clientId": "client_xxx",
    "codeVerifier": "xxx",
    "redirectUrl": "http://example.com/",
    "issuer": "http://example.com/"
  }
}

Workaround

Manual token exchange in solid-logic that:

1. Captures auth code at module load (before library processes it)
2. Reads session data from solidClientAuthenticationUser:* localStorage keys
3. POSTs to /idp/token with PKCE parameters
4. Patches window.fetch to add Bearer token

Code Location

The issue appears to be in handleIncomingRedirect() - it's called but doesn't trigger the token exchange even though all required data is present.

Related

This may be related to timing issues where the library cleans up URL parameters before handleIncomingRedirect is called, or session state management issues.

[NSeydoux]

Hi @melvincarvalho , thanks for reporting this, and thanks for the thorough details.

Can you confirm that there are no error messages logged in the console when the issue manifests? And can you also confirm whether the OpenID Provider you are using is compliant with RFC9207, and includes an iss parameter to the authorization response? Ideally, if you could update to the latest version of the library, that would be great, so that we confirm the issue hasn't been fixed in the meantime (none of the releases after the version you're using seem to be targetting the issue you're describing, but it could have been fixed as a side-effect).