Repository navigation
Silent token refreshing #129
Description
Activity
- Yes, this is indeed the plan; it’s just not implemented yet in the OIDC library we currently use.Reacted by Alex Bourlier
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, Implement refresh() token functionality 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?
Reacted by elf Pavlik, Vincent and Arne Hassel- Node-solid-server (which is currently using the
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 thesession.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'svalidateResponse, which in turn checks whether the session is not actually expired.Thus, it should return
nullfor 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-rplib 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.
Hi guys,
This issue might be somehow related to :
Giving a short lifespan to the
ID tokenis 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-jsseems 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