This change log is intended to record changes made across all packages contained within this mono-repo.
This project adheres to Semantic Versioning.
The following changes have been implemented but not released yet:
4.0.0 - 2026-03-30
Note that these changes are unlikely to impact a client application.
- Replaced
@inrupt/oidc-clientdependency withoidc-client-ts(^3.5.0), the actively maintained TypeScript successor. - Removed re-exports:
Version,CordovaPopupNavigator,CordovaIFrameNavigator(no longer available upstream). - Changed
SigninRequestandOidcClientSettingsto type-only exports.
- A new signature was introduced for
getSessionFromStoragein release 2.3.0. The legacy signature is deprecated, and will be removed with the 4.0.0 major release. Using the more recent API to manage Sessions based on the associated tokens should be preferred, as it allows to not rely on in-memory scale, making it easier to scale horizontally. Prefer usingsession.events.on(EVENTS.NEW_TOKENS, ...)to get the tokens, andSession.fromTokensto build theSessionobject.
// Deprecated signature
const session = await getSessionFromStorage(
sessionId,
storage,
onNewRefreshToken,
refresh,
);
// Replacement signature
const session = await getSessionFromStorage(sessionId, {
storage,
onNewRefreshToken,
refresh,
});- The event
EVENTS.NEW_REFRESH_TOKENis being replaced byEVENTS.NEW_TOKENSwhich returns all the tokens a client can store for refreshing a session.
- Fix issue using the library with Bun by adding missing
extractableflag to the DPoP keys so that they can be serialized on the appropriate events. Thanks to @NoelDeMartin for fixing this issue.
- Sessions built from
Session.fromTokensnow have a correct expiration time triggering refresh in the fetch. Thanks to @NoelDeMartin for fixing this issue.
- Fixed an issue where
handleIncomingRedirect({ restorePreviousSession: true })would redirect to the OAuth provider with expired client credentials, causing users to be stuck on an error page. The library now validates client expiration before attempting silent authentication and gracefully falls back to a logged-out state when the client has expired. Thanks to @timgent for the contribution.
3.1.1 - 2025-10-29
- The
refreshTokensfunction no longer overrides the token type to default toDPoP, and keeps the token type consistent: the resultingSessionTokenSetwill be DPoP-bound or not depending on the inputSessionTokenSet
3.1.0 - 2025-07-08
Session::loginnow supports an additionalcustomScopes: string[]option. It allows developers to specify custom scopes to be added to the authorization request, which will be presented to the user by their OpenID Provider on the consent prompt. If they consent, the issued ID Token may include additional claims based on the requested scopes.
3.0.0 - 2025-07-03
- Support for Node.js v18.x has been dropped as that version has reached end-of-life.
- Fixed the usage of client information from previous dynamic registration that have no expiration date.
2.5.0 - 2025-05-09
- Added a
logoutfunction in the token management API that enables RP-initiated logout for multi-user server-side applications. This complements therefreshTokensfunction introduced in 2.4.0, allowing applications that manage tokens in external storage to both refresh tokens and perform identity provider logout without requiring a Session object. Applications can now implement complete user authentication lifecycle management using token sets stored in their own database. - Added a
EVENTS.AUTHORIZATION_REQUEST(authorizationRequest) event that emits authentication state during login to support clustered deployments. - Added a static
Session.fromAuthorizationRequestState()method that creates a new session from previously stored authentication state.
2.4.1 - 2025-04-18
refreshTokenshad a bug causing an unexpected refresh token rotation if the ID token expired, resulting in the stored token being stale.
2.4.0 - 2025-04-15
- Fix the
Sessionerror listener typing by addingErrorto theerrorDescriptiontype so that it reflects the actual behavior. Thanks to @NoelDeMartin for fixing this issue. - Previously, an application could end up in a bad state when using a dynamically registered client identity beyond its expiration date. A user would be redirected to the OpenID Provider, and end up on an error page unrelated to the application they were trying to log into. Now, expired dynamic clients go through registration again: the user will need to authorize the client after expiration, but will not experience further inconveniences.
- Added a
EVENTS.NEW_TOKENS(newTokens) event to be emitted by theSessionwhen it receives new tokens when a session is initially logged in or refreshed. This event is more useful thanEVENTS.NEW_REFRESH_TOKENwhich is being deprecated. - Added a static
Session.fromTokens(tokens, sessionId)method that creates a new authenticated session directly from a token set, without requiring a full login flow. - Added a new function
refreshTokensto refresh tokens obtained via thenewTokensevent after the Access Token expired.
2.3.0 - 2024-11-14
- The session expiration date (
session.info.expirationDate) is now correct when loading aSessionfrom storage.
- It is now possible to build a
SessionusinggetSessionFromStorageand not log it in using its refresh token. To do so, a newrefreshoptional flag has been introduced. It defaults totrue, which makes this a non-breaking change. In addition, a new signature is introduced to make it easier to provide the optional arguments:
// Legacy signature only specifying one optional argument
const session = await getSessionFromStorage(
sessionId,
undefined,
undefined,
false,
);
// New signature
const session = await getSessionFromStorage(sessionId, { refresh: false });2.2.7 - 2024-10-30
- The IdP logout no longer fails in Node if the session was restored from
storage (using
getSessionFromStorage), which is the typical way server-side sessions are retrieved.
2.2.6 - 2024-09-18
- Repository URL in
package.jsonupdated to set therepository.typeproperty togit. This intends at restoring the previous behavior ofnpm view @inrupt/solid-client-authn repository.url, expected to returngit+https://github.com/inrupt/solid-client-authn-js.git.
2.2.5 - 2024-09-16
- Node 22 is now supported
2.2.4 - 2024-06-24
- Fix the initialization of
clientAppIdinISessionInfoobjects:clientAppIdproperty of theISessionInfointerface, although present, was not being set either in theISessionInfoobjects returned by thehandleIncomingRedirectfunction inClientAuthentication, or in theSessionclass.
-
The
keepAliveoption (introduced in v2.2.0) is now correctly observed in a script using the Client Credentials flow (i.e. using aclientIdand aclientSecretto log in). It previously was disregarded, and theSessionalways self-refreshed in the background.Note that there still is a timeout being set to notify of session expiration, causing NodeJS to wait for the end of the session before closing a terminal. This can be avoided by logging the session out explicitly:
const session = new Session(); await session.login({ oidcIssuer: ..., clientId: ..., clientSecret: ..., });
will hang until the session expires, while
const session = new Session(); await session.login({ oidcIssuer: ..., clientId: ..., clientSecret: ..., }); await session.logout();
will close when logout is complete.
2.2.3 - 2024-06-20
- Fix parsing
clientIdfrom ID Tokenazpclaim: the parsing of the ID Token payload was not correctly extracting theclientIdfrom theazpclaim. As a result,session.info.clientAppIdwas not being initialized upon successful login, which prevented theidplogout of the session from working as expected.
2.2.2 - 2024-06-18
- Maintain token type in
getSessionIdFromStorage: When loading a session from storage on the server (usinggetSessionIdFromStorage), the token type (i.e. DPoP-bound or not, referred to as Bearer) is now consistent with the token type initially associated with the session. Previously, regardless of the token type requested when logging the session in, the token type defaulted toDPoPwhen logging the session back in on load from storage, causing authentication issues.
2.2.1 - 2024-06-04
- Fix #3518: Prevent refresh token from being persisted in local storage.
2.2.0 - 2024-05-03
- It is now possible to prevent a
Sessionself-refreshing in NodeJS. To do so, a new parameter is added to the constructor:Session({ keepAlive: false }). This prevents theSessionsetting a callback to refresh the Access Token before it expires, which could cause a memory leak in the case of a server-side application with many users. It also avoids unnecessary requests being sent to the OpenID Provider.
2.1.0 - 2024-03-13
- OpenID Providers with multiple JWK in their JWKS are now supported. Thanks to @pavol-brunclik-compote for the original contribution.
- Authorization code flow for statically registered clients is now supported. Statically registered clients previously defaulted to the Client Credentials flow, it is no longer an assumption.
- Fix non-DPoP bound tokens support in browser: a bug in the handling of non-DPoP-bound tokens was
preventing the auth code grant to complete, with a 401 to the OpenId Provider Token Endpoint
observed on redirect after the user authenticated. It is now possible to do
session.login({/*...*/, tokenType: "Bearer"})and get a successful result.
2.0.0 - 2023-12-20
- Node 16 is no longer supported. The global
fetchfunction is used instead of@inrupt/universal-fetch. This means this library now only works with Node 18 and higher. - The
Sessionclass no longer extendsEventEmitter. Instead, it exposes aneventsattribute implementingEventEmitter. We do not recommend to useSessioninstance'seventsattribute as an arbitrary events emitter, and encourage users to only use the supported events and documented API. SessionmethodsonLogin,onLogout,onError,onSessionRestore,onSessionExpirationandonNewRefreshTokenhave been removed. They are replaced by calls tosession.events.on, using the appropriate event name.Sessionconstructor changes:- the
onNewRefreshTokenparameter is no longer supported. Its usage is replaced by callingsession.events.onusing theEVENTS.NEW_REFRESH_TOKENconstant as a first parameter, and a callback handling the token as a second parameter. - The
useEssSessionparameter is no longer supported.
- the
- The
getClientAuthenticationWithDependenciesis no longer exported as part of the public API, and is now internal-only. - The UMD build of
@inrupt/oidc-client-extis no longer available. Since this is a package only intended to be consumed by@inrupt/solid-client-authn-browser, which doesn't have a UMD build, this change should have no impact.
- Moved from
rollup-plugin-typescript2to@rollup/plugin-typescript. Although this should not be a breaking change, upgrading may require extra attention.
1.17.5 - 2023-11-16
- This refactors how the the node-based end-to-end tests run to make it possible to run them without having playwright installed. This should not impact downstream consumers.
1.17.4 - 2023-11-09
- Support for
issparameter: RFC9207 adds anissparameter to the callback IRI, and the Node library wasn't removing it before comparing the effective callback URL to the URL used when making the Authorization request.
1.17.3 - 2023-10-10
- Mismatching redirect URI on refresh: the root cause of the bug was a race condition because of the asynchronous nature of updating the browser URL. The appropriate event is now awaited for, which should prevent the issue from manifesting.
1.17.2 - 2023-09-15
- Mismatching redirect URI on refresh: this bug was caused by an invalid redirect URL stored with session data. Saving an invalid redirect URL is now prohibited, and in addition the storage of users impacted by this bug will be cleared so that they don't have to do anything manually to clear their local storage. Users affected by this bug will be asked to log back in, as if they logged out.
1.17.1 - 2023-07-15
- The
fetchfunction is now bound to the window object in all uses withinauthn-browser
1.17.0 - 2023-07-14
- Support for RP-Initiated Logout in Node and Browser libraries.
- ESM support for Node and Browser packages.
1.16.0 - 2023-05-09
- Node 20 support
1.15.0 - 2023-04-17
- Node 18 support
1.14.0 - 2023-03-23
- The
Sessionexposes aneventsattribute implementingEventEmitter, with type hints to guide which events are supported. It allows to register a callback listening on events usingsession.events.on, but also to unregister a callback usingsession.events.off, or to register a one-off callback usingsession.events.once. This attribute intends at replacing exisingSessionmethods to listen on events, namelyonLogin,onLogout,onError,onSessionRestore,onSessionExpiration,onNewRefreshToken.
- The session expiration date was incorrectly computed in the authorization code flow.
1.13.4 - 2023-03-16
- v1.13.3 introduced a bug in the silent reload flow, resulting in a "Mismatching redirect URL" error when refreshing a page with an app logged in. This regression went unnoticed because of a misconfiguration of the browser-based test app that should have covered this scenario. Both issues are now resolved.
- The
Sessionexpiration date was not set in all contexts:session.info.expirationDatewasn't set properly using Client Credentials.
-
Added
eventsattribute to theSessionclass to expose fullEventEmitterAPI with type hints for each supported event. This allows to write code such as the following:const mySession = new Session(); mySession.events.on(EVENTS.LOGIN, () => { console.log("Logged in!"); });
This is closer to the EventEmitter API, so it should be familiar to more developers.
- No longer remove the last issuer URL path component if it doesn't have a trailing slash: a bug was introduced in baac030d33163ba08dadebabdaf676450be7fa88, resulting in the issuer configuration discovery failing if the issuer URL had a path that did not end with a trailing slash. This is now fixed.
- The Client Credential flow had a bug where the expiration time set by the OpenID Provider for the token was ignored, and an arbitrary default was applied instead. This resulted in the session being unable to make authenticated requests, but still acting as if it were logged in. The session now uses the expiration time set by the OpenID Provider.
- Updated transitive dependencies to fix GHSA-rc47-6667-2j5j
- The redirect URL provided to the
loginfunction was being normalized, which could result in misalignments with the redirect URLs declared in a Client Identifier document, since the latter wasn't being normalized. The normalization step has now been removed, and the redirect provided by the user is sent to the OpenID Provider unchanged.
- Added support for RFC 9207
- Clean up
issparameter from redirect URL after redirect
- Upgrades dependencies
- Upgrades dependencies
- Multiple dependencies updates.
- Make support for Node engines explicit.
- Fix incompatible type definitions for
fetchfollowing changes to the typescript definitions.
- Support for Node.js v12.x has been dropped as that version has reached end-of-life.
- We've cleaned up dynamic client registration by removing support for the registrationAccessToken / initialAccessToken when performing the registration flow as this feature was never fully implemented. For Solid apps we recommend the use of a Public Client Identifier Document
- We've also removed support for the iframe-based session renewal, which was never fully implemented.
- Removed immediate use of
windowin Session constructor of the browser package
- the
useEssSessionoption is deprecated, and the associated session endpoint is no longer used. Note that this option defaulted to false, and no public ESS instance was enabling this endpoint, so unless you were explicitly using this feature in an ESS instance you were running yourself, this change should not affect you. If you were using this in a demo app, you may want to clear its local storage.
- The refresh flow was broken for browser-based applications using a client identifier, leading to short session lifetime. Now that this is fixed, the background refresh will happen normally, and the session will remain active.
- The incoming redirect sometimes left OAuth parameters on the URL, despite already having consumed them, this only happened in certain error scenarios, but now the parameters will always be removed, such that the user doesn't get stuck at an error.
- The client credential flow as implemented by the Community Solid Server Identity Provider is now supported. See the documentation for more details.
- @inrupt/oidc-client-ext: remove ts-jest from package dependencies.
- The PKCE verifier is now cleared from storage as soon as it has been used in the token exchange, regardless of the token type (it used to not be cleared from part of the storage when getting a DPoP-bound token).
- Silent authentication is only attempted once, and no longer retries indefinitely on failure.
- Default values are provided for the OIDC Provider supported scopes if not present in the configuration. This fixes #1991.
No changes; fixed issue with npm publish.
- The HTU field of the DPoP header is now normalized to remove the query parameters. Thanks to @diegoaraujo for his first contribution to the project!
- The Solid-OIDC discovery implemented a deprecated method, and is now updated to align with the latest Solid-OIDC specification.
- Using a Client Identifier caused authentication issues at the token endpoint.
- Passing custom headers to a session's fetch as a Headers object would result in the headers being overlooked.
- As per the Solid-OIDC spec, the
webidscope is now added to token requests. - The ID token is no longer kept in storage.
- Since
oidc-clienthas been deprecated, and won't be maintained anymore, the OIDC package now depends on a fork,@inrupt/oidc-client, so that we can ensure the dependencies are kept up-to-date. This should be transparent for users of@inrupt/solid-client-authn-browser.
- When dynamically registering a Client to a Solid Identity Provider, the subject
type was incorrectly set to
pairwise, instead ofpublic. Onlypublicmakes sense in the context of Solid, where subjects (in this case, users) are uniquely identified by their WebID. This was disregarded by current Solid Identity Providers, so it should not have affected dependants, but it's technically more correct.
- The
prompt=consentparameter was missing when redirecting the user to the Solid Identity Provider authorization endpoint. This prevented working with the Community Solid Server Identity Provider. - Proactive refreshing of the token prevented NodeJS from shutting down gracefully. Logging out now clear the timeout previously set, which resolves the issue.
- When dynamically registering a Client to a Solid Identity Provider, the subject
type was incorrectly set to
pairwise, instead ofpublic. Onlypublicmakes sense in the context of Solid, where subjects (in this case, users) are uniquely identified by their WebID. This was disregarded by current Solid Identity Providers, so it should not have affected dependants, but it's technically more correct.
- The
prompt=consentparameter was missing when redirecting the user to the Solid Identity Provider authorization endpoint. This prevented working with the Community Solid Server Identity Provider.
- Use refresh tokens to keep the sesion alive: The browser client now requests a refresh token, and uses it when its access token is about to expire to get a new access token. This enables keeping a session alive for longer than the lifetime of a single access token.
- The
Sessionclass now exposes anonErrormethod, which is a hook where error-handling callbacks may be registered. - The
Sessionclass now exposes anonSessionExpirationmethod, which is a hook where a callback may be registered to handle session expiration in the case when silent authentication fails.
- Trying to log a session in providing dynamically registered client credentials along with a refresh token was mistaken for a static client login, leading to an "Invalid client credentials" error.
- A transitive dependency used submodule exports, which aren't supported yet by significant parts of the ecosystem, such as Jest. With an internal change, we enabled using @inrupt/solid-client-authn-node without encountering submodule exports.
- DPoP-bound refresh tokens are now supported, which allows for an increased protection against refresh token extraction.
- Client credential grant: for Solid Identity Providers which support it, a client may statically register, and use the obtained credentials (client ID and secret) to log in to an Identity Provider. This is convenient in some cases, such as CI environment. However, it requires offline provider/client interaction, which does not scale well in the decentralized ecosystem of Solid. As such, it should only be used in specific cases, where the user is able to statically register their app to their identity provider (which requires some technical background).
- When not using a bundler that automatically provided a polyfill for Node.js
built-in modules, the
eventspackage had to be installed manually.
- Trying to call
Session.fetchfor a Session that had not yet authenticated would result in the following error: 'fetch' called on an object that does not implement interface Window.
- The SessionManager has been removed. Since there is no active use of this class that we are aware of, we are not bumping the major version for this.
- The SessionManager has been removed. Since there is no active use of this class that we are aware of, we are not bumping the major version for this.
- solid-client-authn-browser is no longer dependent on (polyfills being
available for) modules built into Node.js but not available in the browser,
except for
events, which will be removed later. This should not cause any change in behaviour, but let us know if you encounter any issues.
- If
restorePreviousSessionwas set to true, yet the user's session at their Pod server had expired, the Promise returned byhandleIncomingRedirectwould never resolve. - When initialising a new
Sessionin Node, e.g. when doing server-side rendering, an error would be thrown about trying to accesswindow.
- The
popUpoption for theloginmethod, although listed in the API docs, never had any effect. It has now been removed. - The Promise returned by
loginwill no longer resolve, because no code is able to reliably run after it is called; it redirects the user away from the app and thereby terminates all running scripts.
- With Node.js version 10 reaching end-of-life on 2021-04-30, @inrupt/solid-client-authn-node no longer actively supports it. It will not stop working right away, but it will no longer be actively tested and no special effort will be made to keep it from breaking.
- Node.js version 16 is now supported.
- The workaround to maintain sessions in 1.6.1 has been disabled by default;
this means you should see no more (failed) calls to
/sessionin your network console. If you want to make sure a session is preserved across page reloads, please see the documentation on using therestorePreviousSessionoption. If you are working with an instance of ESS that still has the dedicated/sessionyou can still enable this workaround to maintain the previous behaviour.
The following sections document changes that have been released already:
- It is now possible to specify a callback when constructing a function in order to invoke custom code when the refresh token is rotated. This is useful for users who wish to run authenticated scripts, without implementing a brand new storage.
- The OIDC issuer profile is used to negotiate the preferred signature algorithm for ID tokens.
- During client registration, the client explicitly specifies both the 'refresh_token' and the 'authorization_code' grants as part of its profile, instead of only relying on scopes to get refresh tokens. Depending on the Identity Provider, the former behaviour could result in not getting refresh tokens.
- When the token endpoint returns an error message, it is now bubbled up properly.
- Building the browser package is now possible on Windows, thanks to more portable scripts.
- Asynchronous calls that lead to a redirection when restoring a session are now
blocking, to prevent the error associated to the message
Field [sessionId] for user [...] is not storedthat gets thrown when the user is redirected back from the identity provider.
- When loaded in the same environment (e.g. a full-stack NextJS app), it is no longer possible that the browser and node code get mixed together, resulting in code being executed in the wrong environment.
- A client WebID can now be provided as part of the
loginoptions. The library will check for compliance of the chosen Solid Identity Provider, and go use the provided client WebID or go through Dynamic Client Registration accordingly.
- Attempting to log in with a hash fragment in the redirect URL no longer throws, the hash fragment is simply discarded.
- The ID token is now validated when asking for DPoP-bound tokens, and not only when asking for a Bearer token.
- The OIDC parameters added to the redirect IRI by the Solid Identity Provider are no longer included in the redirect IRI provided at the token endpoint.
- The provided redirect IRI is now normalized.
- Fixed a typo in the TypeScript interface IHandleIncomingRedirectOptions.
- New option
useEssSessionforsession.handleIncomingRedirect: Control to enable and disble the behaviour introduced in 1.4.0. If set to false, the/sessionendpoint isn't looked up, and cookie-based auth is disabled. The behaviour is similar whenrestorePreviousSessionis true.
- Some components of the redirect URL are no longer lost after redirect, which prevents silent authentication from failing.
- The first parameter to
Session.handleIncomingRedirectis now an options object. If you want to pass in the URL to handle, you can now do so by setting theurlproperty on the options object. Passing the URL directly as the first argument (which has been optional since version 1.5.0, defaulting towindow.location.href) is still possible, but is now deprecated and thus might be removed in a future major release.
- Version 1.6.0 automatically redirected the user away from your app after a
page refresh if they had signed in previously, losing all application state.
This now no longer happens; instead, you can opt in to automatically restoring
a user's session after reloading the page by passing a
restorePreviousSessionboolean tohandleIncomingRedirect, and listening for thesessionRestoreevent (or passing a callback toonSessionRestore) to restore your application state. - No longer send PKCE-related information during DCR, when they are irrelevant.
validateIdToken: A function to check that an ID token has been signed by the correct issuer, and that it contains some expected values.
- Added new
onSessionRestoreevent toSession(and default session) to allow the developer to register an event callback that will be called whenever a session is restored (e.g., due to a browser page refresh). The callback is given a URL parameter, which represents the current URL of the browser before the session restoration (to allow the developer to restore their app's state if needed, e.g., if the app is a Single Page App (SPA) and the developer wishes to restore the users 'current page' to exactly where they were before the refresh).
- Refreshing the page no longer logs the session out, no matter what Resource Server the data is collected from.
- When a session expires, the session is now marked as logged out, and a
logoutevent is thrown. - The 'client_id' option, if specified as an option when logging in, is now stored in storage, ready to be retrieved again from storage when the login flow redirects back to the client application (previously it was only being stored if DCR was invoked).
- The issuer URL associated with the session is now necessarily the canonical issuer's URL, instead of potentially including/missing a trailing slash.
- Deprecated SessionManager
- The implicit flow is no longer supported. However, no known Solid Identity issuer only supports the implicit flow and not the auth code flow, and no user-facing controls enable choosing one's flow, so this has no user impact.
- store the user's issuer claim, specifically to 'localStorage' to allow retrieval on tab refresh.
- Logging out of an app opened in multiple tabs logged the user back in automatically.
handleIncomingRedirectuses the current browser URL as a default value.
getSessionFromStorage: a function to retrieve a session from storage based on its session ID (for multi-session management).getSessionIdFromStorageAll: a function to retrieve the session IDs for all stored sessions.clearSessionFromStorageAll: a function to clear all information about all sessions in storage.
- Any exception thrown by the custom
/sessionendpoint lookup is swallowed.
- Building multiple sessions with the default storage re-initialized a new storage each time.
- The
onLogincallback couldn't read session information, such as the WebID.
- For
solid-client-authn-node, thesecureStorageandinsecureStorageare deprecated, and replaced bystorage.
- The
Sessionconstructor in solid-client-authn-browser no longer referenceswindowso that it can be instantiated in a non-window context (although it will continue to referene window.localstorage when you attempt to log in.)
- Updating the browser window will no longer log the user out if their WebID is
hosted on an ESS instance (such as https://pod.inrupt.com). A better, global
solution will be implemented later in order not to break compatibility in the
ecosystem. The current solution is based on a custom
/sessionendpoint lookup, and a Resource Server cookie.
- Although still possible, it is now no longer required to manually instantiate
a new
Sessionobject when usingsolid-client-authn-browser. Instead, you can directly importfetch,login,logoutandhandleIncomingRedirect, which will instantiate a new Session implicitly behind the scenes. If you do need access to this Session, you can do so using the new functiongetDefaultSession.
- The
session.info.isLoggedInproperty is now set to false on logout.
- Adds "main" entry to browser packages
- Credentials for statically registered clients weren't stored, which failed the token exchange.
ajvwas imported through a dependency instead of being explicitly declared as a direct dependency ofsolid-client-authn-core
- The
browserentry in thepackage.jsonwas incorrect, leading to issues when bundling the library.
- The WebID is now REALLY set on the session when logging in a script. The initial fix introduced in 1.2.1 did compute the WebID from the identity provider response, but did not set it properly on the session.
The following sections document changes that have been released already:
- Addressed part of issue #684,
by providing a
browserentry in thepackage.jsonfile. The ES modules export will be adressed in a different PR. - The WebID is now set on the session when logging in a script.
- When logging in with a refresh token (e.g. for a script), if the provided credentials are incorrect, an error is thrown.
- Support for authenticated scripts: It's now possible to provide a script with login parameters for a refresh token, a client ID and a client secret, which enables it to access private resources on Pods. This means that it's now easier to write small backend scripts which can interact with Pods in an automated way (i.e. no human interaction required).
- In some use cases (e.g. authenticating a script), logging in happens without a redirection. The architecture so far prevented this from being possible, and now after a login that does not require a redirect, the current session may be authenticated.
- Logging in a browser app will now clear OIDC-specific query params from the URL, which prevents a crash on refresh.
- issue #685 fixed by removing all URL query params after login, which prevents from crashing when reloading a page.
- updated version of
solid-common-vocabto pull in common RDF/JS types.
- NodeJS support: a new NPM package,
@inrupt/solid-client-authn-node, is now available to use authentication in a server environment. - In addition to the features supported by the browser version,
@inrupt/solid-client-authn-nodesupports the refresh token grant, which makes it possible to maintain long-lived sessions without re-involving the user.
- Deriving the WebID from the ID token did not accept some valid IRIs in the subject claim, i.e. issued by a local instance of Node Solid Server.
There is no breaking change in this release, but from now on, as per semantic versioning, we will bump the major version when we change our publicly documented interface.
- The expiration claim has been removed from the DPoP token, where it is not needed.
- There were dependency upgrades.
- The package
@inrupt/oidc-dpop-client-browseris now called@inrupt/oidc-client-ext. - The public API doesn't expect environement-specific types anymore. in particular,
URLhas been replaced withstring.
- It is now possible to build a
Sessionwithout callinggetClientAuthenticationWithDependencies, which results in simpler code.
- If
handleLoginis called twice, the token endpoint is only hit once, because it might reject replay of the authorization code. - A DPoP-authenticated request now follow redirects (in particular, forgetting the trailing
/for a container no longer returns 401).
- TestCafe test suite now tests with real tests against both NSS and ESS.
- The support for DPoP was re-implemented in @inrupt/oidc-client-dpop-browser, such that the DPoP JWK is never stored, and only kept inside the closure of the authenticated fetch.
- The Authorization header was not set properly, which made it impossible to access private resources.
- The types consumed/returned by the API are now exported for convenience.
- The URL parsing library did not parse properly some redirection IRIs, this is now fixed.
- The dynamic client registration could hang depending on the environment it was deployed in, this is now resolved.
- The
loginevent was never actually fired because of a bug which is now fixed.
- Fixed typo in
detachSessionfunction name for the browserSessionManager.
- Uses oidc-client-js now to perform the Auth Code Flow (replacing lots of hand-rolled code).
- Source files are now also published to npm, so source maps should work from now on.
- Fixed typo in
detachSessionfunction name for the browserSessionManager.
- Browser
- Login now clears the local storage, so that you can log into a different server even if not logged out properly.
- Created multiple sub-packages, specifically the core and oidc-dpop-client-browser.
- Moved interfaces down into Core.
- Removed TSyringe annotations from the implementation of StorageUtility in the Core package and extended it in the browser module (where they we re-applied to allow injection again).
- Refactored the StorageUtility code to fix up mock usage.
- Moved to Lerna (currently only the browser module is available).
- Browser:
- The code wasn't shipped properly when publishing a non-dev release to NPMJS.
First release! What's possible with this first release:
- Authenticate a Web app to a Solid Identity provider
- Perform an authenticated fetch to a Pod Server, using a DPoP token