Client dynamic registration - issues when provider invalidates cached client_id

[timgent]

Search terms you've used

handleIncomingRedirect restorePreviousSession invalid_client, client_id expired session restore, prompt=none invalid client redirect, session restore blocking error

Impacted package

Which packages do you think might be impacted by the bug ?

• solid-client-authn-browser
• solid-client-authn-node
• solid-client-authn-core
• oidc-client-ext
• Other (please specify): ...

Bug description

When handleIncomingRedirect({ restorePreviousSession: true }) is called with stored session data containing an invalidated/expired client_id, the library immediately redirects to the OAuth provider with the invalid credentials before our application can handle the error. This results in a 401 "invalid_client_id" error that completely blocks users from accessing the application, with no programmatic recovery path.

Users who return to our app after extended periods (when their dynamically registered client has been invalidated by the OAuth provider) are unable to use the application. The only recovery is manually clearing browser data, which most users don't know how to do.

To Reproduce

1. Log in to a Solid Pod provider successfully (creates dynamic client registration, stores client_id in browser)
2. Close the browser (session data remains in IndexedDB/localStorage)
3. Wait for OAuth provider to invalidate the client registration (or manually delete it from provider's admin panel if possible for testing)
4. Open the app again
5. Observe: Immediate redirect to authorization endpoint with the now-invalid client_id
6. Observe: 401 "invalid_client_id" error page from OAuth provider

Our code:

import { handleIncomingRedirect, getDefaultSession } from '@inrupt/solid-client-authn-browser';

useEffect(() => {
  const initSession = async () => {
    try {
      await handleIncomingRedirect({ restorePreviousSession: true });
      const session = getDefaultSession();
      setSession(session);
    } catch (error) {
      console.error("Session initialization error:", error);
      // This never fires for invalid client_id scenarios
      await solidLogout();
    }
  };
  initSession();
}, []);

Expected result

We're not sure what the intended behavior should be, but we would expect one of:

1. The library validates stored client credentials before initiating silent auth, clears invalid session data automatically, and returns a logged-out session
2. The error is catchable in our try/catch block so we can handle it programmatically
3. A way to inspect/validate stored session data before calling handleIncomingRedirect() so we can clear corrupted data proactively

Ideally, users wouldn't be blocked from accessing the application due to expired OAuth credentials stored in their browser.

Actual result

When the user visits the app:

1. handleIncomingRedirect({ restorePreviousSession: true }) is called
2. The library immediately redirects to the OAuth provider (before our code continues):

   https://login.inrupt.com/authorization?
     client_id=22fe30ba-129c-46ed-843c-e8f28debdb16
     &prompt=none
     &redirect_uri=https%3A%2F%2Freact-packing-app.vercel.app%2Fpod-auth-callback.html
     &response_mode=query
     ...
   

3. OAuth provider returns 401 with "invalid_client_id" error
4. User is stuck on the error page
5. Our try/catch block never catches any error (presumably because the redirect happens synchronously before the Promise is created)

The user cannot access the application. Manual browser data clearing is required to recover.

Environment

$ npx envinfo --system --npmPackages --binaries --npmGlobalPackages --browsers

System:
  OS: Linux (Vercel deployment + local development)
  Browser: Chrome/Firefox/Safari (reproducible across all)

Binaries:
  Node: 18.x
  npm: 9.x

npmPackages:
  @inrupt/solid-client: ^2.1.2
  @inrupt/solid-client-authn-browser: ^3.1.0
  @inrupt/vocab-common-rdf: ^1.0.5
  @inrupt/vocab-solid: ^1.0.4

Production app affected: https://react-packing-app.vercel.app

Additional information

Our Understanding (Please Correct If Wrong)

From our investigation, it appears that when restorePreviousSession: true, the library immediately initiates a silent auth redirect (prompt=none) before handleIncomingRedirect() returns its Promise. If the stored client_id has been invalidated, the redirect happens anyway with invalid credentials. Since the redirect is synchronous, our try/catch cannot intercept it.

We may be misunderstanding how this is intended to work.

Questions We're Hoping You Can Help With

1. Is this the intended behavior when stored client credentials become invalid? Should applications expect this scenario?

2. Is there a recommended pattern for handling invalidated client_ids that we're missing? Should we be doing something differently in our setup?

3. Is there a way to detect or validate stored session data before calling handleIncomingRedirect() so we can clear it proactively if needed?

4. Would it make sense for the library to handle this scenario internally (e.g., detecting the invalid client and clearing session data automatically), or is that something applications should manage?

5. For restorePreviousSession: true to be safe in production, what assumptions should we make about client_id lifetime and validity?

Temporary Workaround We're Considering

await handleIncomingRedirect({ restorePreviousSession: false });

This would require users to explicitly log in after each page refresh, losing the seamless "stay logged in" experience, but prevents the blocking issue entirely.

Would this be the recommended approach, or is there a better pattern we should follow?

Related Issues/Discussions We Found

• #3443 - Discusses challenges with silent authentication redirects
• #1790 - Dynamic client ID issues
• #1989 - Query string handling with restorePreviousSession
• Forum discussion on invalid_client errors

We appreciate any guidance you can provide on the recommended way to handle this scenario!

[NSeydoux]

Hi @timgent, thanks for reporting this.

What you are describing is indeed a bug, and not the intended behavior. It looks very similar to what should have been fixed with https://github.com/inrupt/solid-client-authn-js/releases/tag/v2.4.0. As you are suggesting, a temporary workaround would be to set restorePreviousSession to false, so that the library doesn't load the stored state and doesn't end up on the OpenID Provider error page, which is then out of control of the library code.

Currently, the intended behavior is that upon registration, the library stores the expiration date of the client credentials in local storage, and verifies that when attempting to log in, the client credentials have not expired. Can you check the response from the registration endpoint and confirm that an expiration date is present?

If it is an option, I would encourage you to use a Solid-OIDC Client ID document (our documentation describes this in a bit more details this mechanism, which is specified here. Using such a client ID document provides a stable, persistent identity to your application, and therefore makes the whole issue of client registration and client identifiers management moot.

[timgent]

Thanks @NSeydoux . Is this the response you are talking about?

Request
URL: https://login.inrupt.com/token
Method: POST

Response body

{
    "access_token": "xxx",
    "id_token": "xxx",
    "refresh_token": "xxx",
    "token_type": "DPoP",
    "expires_in": 300,
    "scope": "offline_access webid openid"
}

[NSeydoux]

Not quite: this is a response from the token endpoint, which happens later in the client lifecycle. Before this, when you connect with the client "for the first time" (so without existing cookies), you should have a request to https://login.inrupt.com/registration.

[timgent]

Ah got it, looks like it is returning an expiration date as expected - client_secret_expires_at:

{
  "client_id": "xxx",
  "client_secret": "xxx",
  "client_secret_expires_at": 1769121962,
  "redirect_uris": [
    "https://react-packing-app.vercel.app/pod-auth-callback.html?returnTo=%2F"
  ],
  "client_name": "Pack Me Up",
  "grant_types": [
    "refresh_token",
    "authorization_code"
  ],
  "response_types": [
    "code"
  ],
  "application_type": "web",
  "contacts": [],
  "token_endpoint_auth_method": "client_secret_basic",
  "id_token_signed_response_alg": "ES256"
}

[timgent]

@NSeydoux I've had a little go at a PR for a fix (disclaimer - Claude Code has done it, I've just tried to nudge it in what I hope is the right direction).

Would be great if you have a few mins for an early review. PR is here: https://github.com/inrupt/solid-client-authn-js/pull/4181/files