I am not a cryptographic nor a browser security expert. I was wondering where there was more information / documentation I could read to understand Solid’s security & usability design decisions for federated authentication. I understand the initial signin needs your-app.com to redirect to pod-identity-provider.com where your users authenticate before being redirected back to your-app.com with url params containing session info. When this has occurred, why is this information (url parameters of
code) only held in memory and not stored in localStorage?
If it is stored in localStorage then any script running on that subdomain could access the information and send it to a different website from which the users’ session could be misused correct? However the user is still trusting your-app.com to not be malign, i.e. your-app.com can misuse its access to the Solid pod resources you have given it access to. I do not yet understand what the additional security is from not storing the information in localStorage. Is the security model of other websites like Supabase (which stores your session / session refresh tokens in localStorage) making the assumption your-app.com and all the scripts you load on to it are not malign?
A separate but related question is: if your-app.com captures the parameters and saves them to local storage, then when the user refreshes the page your-app.com sets these same parameters before calling
handleIncomingRedirect, does this work or are the url parameters only a one-time use? … I’m asking as if this not a one time use then one could easily subvert the current security model to avoid the “refresh” step, i.e. when a user first logs in you use a custom client that stores code and state in localstorage so if the user immediately refreshes the page they can still use the application straight away without the redirect to the auth service and back to your app (with a new pair of
code url parameters).
And more importantly please, could you point me to where I could have found that answer myself. Thank you. I guess this is in the code somewhere.
I don’t think I’ve worded this very succinctly but any assistance in understanding this security flow would be appreciated.