The caching layers on current main each own a private Map: CachingIssuerProvider, CachingAuthorizationServerProvider, CachingClientProvider, and DPoPTokenProvider. Applications cannot select storage, manage lifetime, or clear these caches through a common contract.
This follows #29's preference for independent provider caches and generalizes the persistence concern in #15. Those issues do not yet specify a shared cache contract. Component separation and refresh support have since landed in #30, #33, #35, #36, #41, and #42.
Proposed scope
- Export a generic asynchronous cache interface with get, set, delete, and clear; inject it into each existing caching component while preserving memory defaults and existing constructor calls.
- Supply memory, explicitly namespaced Web Storage, and IndexedDB adapters. Await durable writes, including refresh-token rotation, and report storage failures instead of silently losing authentication state.
- Provide an explicit browser preset: expiring IndexedDB caches for issuer choices/discovery data; memory for client registrations (which may include secrets) and token material. Applications can explicitly opt into IndexedDB credential persistence.
- Persist a DPoP credential record atomically with its non-extractable CryptoKeyPair; generate a fresh proof for every request. Do not serialize private keys into localStorage/sessionStorage.
- Document isolation between applications, clients, and accounts; storage eviction/unavailability; expiration; and cache clearing versus full logout/revocation.
- Test asynchronous adapters, reload reuse, namespace isolation, write failures, CryptoKey round-trips, token refresh/rotation, and no cached authorization failures.
IndexedDB supports structured storage including CryptoKeys (IndexedDB, Web Crypto). Web Storage is suitable only for explicitly encoded non-secret data. The Credential Management API is not a generic OAuth token cache. Non-extractable keys do not prevent malicious same-origin JavaScript from using keys or credentials: see OAuth for browser applications.
Storage-wide Solid/LWS key resolution is deliberately a separate issue. This change should retain existing request-URL and issuer keys. #15's refresh-only restore policy and #23's logout/supersession semantics remain separate design work; a generic persistence adapter should not claim to implement them.
Storage-wide context/key resolution is tracked separately in #46, with no implementation PR in that scope.
The caching layers on current
maineach own a privateMap:CachingIssuerProvider,CachingAuthorizationServerProvider,CachingClientProvider, andDPoPTokenProvider. Applications cannot select storage, manage lifetime, or clear these caches through a common contract.This follows #29's preference for independent provider caches and generalizes the persistence concern in #15. Those issues do not yet specify a shared cache contract. Component separation and refresh support have since landed in #30, #33, #35, #36, #41, and #42.
Proposed scope
IndexedDB supports structured storage including CryptoKeys (IndexedDB, Web Crypto). Web Storage is suitable only for explicitly encoded non-secret data. The Credential Management API is not a generic OAuth token cache. Non-extractable keys do not prevent malicious same-origin JavaScript from using keys or credentials: see OAuth for browser applications.
Storage-wide Solid/LWS key resolution is deliberately a separate issue. This change should retain existing request-URL and issuer keys. #15's refresh-only restore policy and #23's logout/supersession semantics remain separate design work; a generic persistence adapter should not claim to implement them.
Storage-wide context/key resolution is tracked separately in #46, with no implementation PR in that scope.