Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Silent token refreshing #129

Open
happy-dev opened this issue Jul 13, 2019 · 10 comments
Open

Silent token refreshing #129

happy-dev opened this issue Jul 13, 2019 · 10 comments

Comments

@happy-dev
Copy link

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

@RubenVerborgh
Copy link
Contributor

RubenVerborgh commented Jul 13, 2019 via email

@Vinnl
Copy link

Vinnl commented Sep 25, 2019

Just so I know which issues to subscribe to: is this the blocker? nodeSolidServer/oidc-rp#4

@dmitrizagidulin
Copy link
Contributor

dmitrizagidulin commented Sep 25, 2019

@Vinnl - Ok, so, there's several moving parts here :)

Server-side:

  • Node-solid-server (which is currently using the solid/oidc-op library) 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-rp library 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 likely solid-auth-client itself) will be replaced (similar to how Inrupt Pod Server is using different libraries that are better maintained etc), with oidc-client-js or similar. So that, I suspect, is part of the reason why I don't think anyone is in a hurry to implement refresh tokens in solid/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?

@happy-dev
Copy link
Author

At least, that made things a lot clearer to me. Thank you @dmitrizagidulin

@Vinnl
Copy link

Vinnl commented Sep 26, 2019

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.

@dmitrizagidulin
Copy link
Contributor

dmitrizagidulin commented Sep 26, 2019

@Vinnl:

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.

@dmitrizagidulin
Copy link
Contributor

The other option would be to put the check for expiration in the fetchWithCredentials() function. Or both.

@Vinnl
Copy link

Vinnl commented Sep 30, 2019

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?

@RubenVerborgh
Copy link
Contributor

Not everything is implemented in the underlying OIDC library, and as @dmitrizagidulin wrote above, not likely to happen soon.

@dmitrizagidulin
Copy link
Contributor

@Vinnl

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants