I’d say the full security model is still being finalised, including being able to restrict access to resources based on the client application, i.e. it is ultimately the intention that a non-secure Solid app that is trusted for some data would not be permitted access to more sensitive data.
Yes, avoiding storing secrets in local storage is a strategy used by Inrupt’s solid-client-authn precisely to avoid security vulnerabilities.
Some discussion you might already have come across:
opened 09:41PM - 14 Oct 20 UTC
closed 12:26PM - 05 May 22 UTC
**Describe the bug**
After a successful login, if you refresh the page (or you … lose the auth session instance for any other reason), the application will not still be logged in.
**To Reproduce**
Steps to reproduce the behavior:
1. Run the example at https://github.com/inrupt/solid-client-authn-js/tree/master/packages/browser/examples/single/bundle
2. Log into a server.
3. Refresh the page
**Expected behavior**
Solid-client-authn should use a refresh token to get a new key so that a user stays logged in when they refresh.
**Environment**
```
System:
OS: macOS 10.15.6
CPU: (8) x64 Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz
Memory: 220.08 MB / 16.00 GB
Shell: 5.7.1 - /bin/zsh
Binaries:
Node: 14.4.0 - /usr/local/bin/node
npm: 6.14.4 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
Browsers:
Chrome: 86.0.4240.75
Firefox: 81.0
Safari: 14.0
npmPackages:
@babel/core: ^7.8.6 => 7.10.5
@babel/preset-env: ^7.8.6 => 7.10.4
@babel/preset-react: ^7.8.3 => 7.10.4
@inrupt/solid-client-authn-browser: file://../../../ => 0.2.1
babel-loader: ^8.0.6 => 8.1.0
html-loader: ^0.5.5 => 0.5.5
html-webpack-plugin: ^3.2.0 => 3.2.0
react: ^16.13.0 => 16.13.1
react-dom: ^16.13.0 => 16.13.1
regenerator-runtime: ^0.13.3 => 0.13.7
webpack: ^4.41.6 => 4.44.0
webpack-cli: ^3.3.11 => 3.3.12
webpack-dev-server: ^3.10.3 => 3.11.0
npmGlobalPackages:
@inrupt/generator-solid-react: 0.7.2
@inrupt/solid-auth-fetcher: 0.0.6
expo-cli: 3.27.4
lerna: 3.22.1
npm: 6.14.4
ochat-api: 1.0.0
redis-commander: 0.7.0
static-server: 2.2.1
typescript: 3.9.5
yo: 3.1.1
```
**Additional context**
This probably is just due to the new closure version of storage. To fix this refresh token flow should be triggered upon startup.
I recently started thinking about following an offline-first approach for an app I’m building, and there is an existing limitation with Inrupt’s authentication library that brings some UX challenges.
In particular, the limitation is that authenticating will always trigger a redirect. Most of the time, this redirect works without user interaction so it’s just a minor annoyance. But in the offline-first use-case, this is worse. If the application redirects upon booting up, an offline user would b…
My intuition is also that yes, it would make sense to call handleIncomingRedirect first. This is also the pattern adopted by onSessionRestore. I addition to any possible security risks, it makes sense to restore state only after you know whether your app is authenticated.https://docs.inrupt.com/developer-tools/javascript/client-libraries/tutorial/restore-session-browser-refresh/#session-restore-event-handler