Clarity on Refresh Token vs Access Token In NodeJS

1

Hello,

I am confused about what the difference between a “Refresh Token” and an “Access Token” are while using Node JS applications authorized through Inrupt.

For example,I am supposed to get a refresh token here but it doesn’t explain how to get the initial refresh token., and I have tried to get an access token but have been unsuccessful. Some clarity about this would be really helpful during debugging, as the documentation doesn’t really fill in the blanks.

On the same topic, handling the refresh tokens in a callback is unclear - do I need to reinitatiate a session or reassign the new token in it? This has also been unclear from the documentation.

2

Hi @gaz009!

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 :slight_smile: .

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.

Does this answer your question? And in your use case, would you be able to use a statically registered client (as described in Authenticate (Node.js: Single-User App) — Inrupt JavaScript Client Libraries)?

1 Like
3

Hello, yes it does thanks.

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.