I think an important note before I start is that the refresh token-based login is a deprecated flow, and I thought I had removed it from the docs, so thanks for pointing it out I’ll go ahead and do that .
Then, to your question, an Access Token is a piece of data the Resource Server (the Pod) will be able to verify, and can be used to show you should have access to a specific resource. Obviously, that makes them highly valuable, and they need to be handled carefully. One typical security measure to mitigate risks of Access Token misuse is to reduce their lifetime: if you monitor the @inrupt/solid-client-authn-*Session expiration, it’s around 6 minutes with PodSpaces. However, requiring the user to log in every five minutes is a terrible user experience, and it isn’t even possible for server-side application where the user may not be present when the server needs to make an authenticated request.
That’s where Refresh Tokens come in. A Refresh Token is a piece of data that the issuer of the Access Token (in the current state of Solid, the OpenID Provider), but that is meaningless to the Resource Server: the Refresh Token by itself doesn’t give access to any resource. Another difference between the Refresh Token and the Access Token, which makes sense when you consider what I was saying before, is that Refresh Token have a much longer lifetime than Access Tokens: they will be valid long beyond the session expiration. Their purpose is to allow the server holding a Refresh Token to be able to get a new Access Token.
I am in fact using the WebsocketNotifications with an Inrupt server to try and build a module that writes data into my pod every so often, however an issue I’ve ran into and tested continually is that after about 5 minutes, I can no longer save to the dataset even after I’ve updated. That’s why I was was wondering with Inrupt if there is a token timeout that I needed to work with, though I have been unable to acquire a refresh token or anything like it from the Inrupt Enterprise Server.