When a Solid OIDC provider drops a browser's dynamically-registered client (for example, the provider kept client registrations in memory and restarted), the browser's stored clientId is no longer known to the provider. On session restore, silentlyAuthenticate redirects to the authorization endpoint with the stale clientId and prompt=none.
The provider cannot redirect the error back to the app (it cannot validate the redirect_uri of an unknown client), so it returns a non-redirectable "unknown client" error page (e.g. Community Solid Server returns HTTP 400 E0003 Unknown client). Because KEY_CURRENT_URL is only cleared after a successful silent auth, the next page load re-attempts silent auth with the same rejected clientId — looping indefinitely.
Impact
- Affected users see permanently broken sessions/pods. Clearing localStorage on the app origin does not help, because the stale registration lives on the pod subdomain origin.
- The retry storms add load to the provider. Observed in production against Community Solid Server (solidcommunity.net), where it surfaced as rate-limiting (429s).
Environment
@inrupt/solid-client-authn-browser v5.0.0- Any Solid-OIDC provider using dynamic client registration that can lose registrations (e.g. Community Solid Server with in-memory OIDC adapter storage).
Steps to reproduce
- Log in to an app that uses dynamic client registration against a CSS instance; the session is restored across reloads via silent auth.
- Cause the provider to forget the dynamic client (e.g. restart a CSS instance whose OIDC adapter storage is in-memory).
- Reload the app: silent auth redirects to the provider, gets
400 Unknown client, and on returning to the app re-attempts with the same clientId. The session never recovers.
Expected
On an unknown/invalid client during silent authentication, the library should discard the stored client registration and re-register instead of looping.
Proposed fix
Detect an incomplete previous silent-auth attempt (a KEY_CURRENT_URL still set on re-entry) and discard the stored client registration so the next login re-registers. PR to follow.
When a Solid OIDC provider drops a browser's dynamically-registered client (for example, the provider kept client registrations in memory and restarted), the browser's stored
clientIdis no longer known to the provider. On session restore,silentlyAuthenticateredirects to the authorization endpoint with the staleclientIdandprompt=none.The provider cannot redirect the error back to the app (it cannot validate the
redirect_uriof an unknown client), so it returns a non-redirectable "unknown client" error page (e.g. Community Solid Server returns HTTP 400E0003 Unknown client). BecauseKEY_CURRENT_URLis only cleared after a successful silent auth, the next page load re-attempts silent auth with the same rejectedclientId— looping indefinitely.Impact
Environment
@inrupt/solid-client-authn-browserv5.0.0Steps to reproduce
400 Unknown client, and on returning to the app re-attempts with the sameclientId. The session never recovers.Expected
On an unknown/invalid client during silent authentication, the library should discard the stored client registration and re-register instead of looping.
Proposed fix
Detect an incomplete previous silent-auth attempt (a
KEY_CURRENT_URLstill set on re-entry) and discard the stored client registration so the next login re-registers. PR to follow.