Silent token refreshing
happy-dev opened this issue · 10 comments
Hi guys,
This issue might be somehow related to :
Giving a short lifespan to the ID token is a security feature to reduce the vulnerability surface, but as @dmitrizagidulin said it is inversely proportional to user convenience.
We are currently experiencing this pain in our app. So far our only option is to increase the lifetime of the issued tokens, which is not the recommended way to go.
How about silent token refreshing ?
Brock Allen, the author of oidc-client-js seems to think it is acceptable in terms of security. I am having a hard time assessing if it is.
It is on the roadmap ?
If it isn't, how do we intend to make long sessions work with security.
Many thanks for your insight
Just so I know which issues to subscribe to: is this the blocker? nodeSolidServer/oidc-rp#4
@Vinnl - Ok, so, there's several moving parts here :)
Server-side:
- Node-solid-server (which is currently using the
solid/oidc-oplibrary) does not have Refresh tokens implemented. Which is OK, because it's being replaced by: - Inrupt Pod Server DOES have Refresh tokens implemented.
Client-side:
- solid-auth-client (this repo) uses the
solid/oidc-rplibrary under the hood. Which does not currently have Refresh tokens implemented, and yes, nodeSolidServer/oidc-rp#4 is the blocker/tracking ussue. - But! It is assumed that on the client side,
solid/oidc-rp(and likelysolid-auth-clientitself) will be replaced (similar to how Inrupt Pod Server is using different libraries that are better maintained etc), withoidc-client-jsor similar. So that, I suspect, is part of the reason why I don't think anyone is in a hurry to implement refresh tokens insolid/oidc-rp. Especially because:
Protocol-side:
- Solid's authentication protocol, WebID-OIDC, is currently being refactored and standardized (in the authentication-panel). So that, I suspect, is also playing into the delay, since people want the protocol to settle down before coding more. :)
Does that make sense? So, yes, oidc-rp/4 is the blocker (if you're planning to use it with Pod Server), but I don't think resources have been allocated to it?
At least, that made things a lot clearer to me. Thank you @dmitrizagidulin
Thanks @dmitrizagidulin, that's very clear.
Short other question: is it theoretically already possible for solid-auth-client to know when the token has expired? Even if we're not able to refresh the token yet, it'd be great to at least be able to let the user know they're logged out, rather than things just suddenly no longer working.
is it theoretically already possible for solid-auth-client to know when the token has expired?
It would be, yeah.
You'd want to add some code probably around here in currentSession() L48-56, checking the session.idClaims.exp (expiration) claim, and throw an error if it's expired.
The other option would be to put the check for expiration in the fetchWithCredentials() function. Or both.
Hmm, so I've done some digging here, but it doesn't seem like this should need extra logic in currentSession(): solid-auth-client currently calls @solid/oidc-rp's validateResponse, which in turn checks whether the session is not actually expired.
Thus, it should return null for expired sessions (I have a unit test that verifies this). So the question to investigate should be: how come it appears that it does sometimes not return null on an expired session?
Not everything is implemented in the underlying OIDC library, and as @dmitrizagidulin wrote above, not likely to happen soon.
how come it appears that it does sometimes not return null on an expired session?
I haven't looked closely, but I suspect it has to do with the difference in lifetime between the inner ID Token (really, just a signed credential) and the outer PoP token. Both have different expiration times that the auth client has to consider, and the oidc-rp lib mostly focuses on the ID Token's expiration, and not the interaction between the two.
So, yeah, it shouldn't be too hard of a lift to fix, I agree.