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

Introduce expiration on refresh tokens - an implementation proposal #288

Open
vjt opened this issue Apr 21, 2021 · 6 comments
Open

Introduce expiration on refresh tokens - an implementation proposal #288

vjt opened this issue Apr 21, 2021 · 6 comments

Comments

@vjt
Copy link
Contributor

vjt commented Apr 21, 2021

Greetings!

By reading the refresh token mapper code it seems to me that refresh tokens do not have an expiration time, as such they are potentially valid forever, as long as the underlying user is still active it its backend.

In some high-security contexts, users are requested to re-login periodically, to reduce the risk of token stealing.

What do you think of:

  • Add new "refresh token expiration days" setting
  • Add a new expires_at timestamp column on the refresh tokens table
  • When issuing a new refresh token, store time() + $refresh_token_expiration_days in the expires_at
  • When refreshTokenMapper#findByToken() is called, it would select * from refreshtokens where token = ? and expires_at > NOW()
  • Add a new cron job to delete from refreshtokens where expires_at < NOW()

Thank you!

@michaelstingl
Copy link

@vjt refresh tokens get renewed too and get invalidated after single use. Token stealing not possible from my pov.

@vjt
Copy link
Contributor Author

vjt commented Apr 21, 2021

@michaelstingl thanks. The stealing is indeed difficult, as that would require getting control of the state of an active client.

Still, being refresh tokens valid forever, they pose some concern for our context, as our policies require users to re-authenticate periodically.

What do you think?

Thank you

@michaelstingl
Copy link

For more control, policies etc, better use OpenID Connect:
https://doc.owncloud.com/server/10.7/admin_manual/configuration/user/oidc/oidc.html

Policies configured on your IdP are used to control not only the oC server, but also desktop & mobile clients behave according those policies. OpenID Connect also prepares you to migrate to the next generation ownCloud based on Golang microservice architecture:
https://owncloud.dev/ocis/migration/

@vjt
Copy link
Contributor Author

vjt commented Apr 21, 2021

Ouch, that migration would not be straightforward at this time, but I understand one can be more focused on the upcoming technology rather than extending the current.

Anyway - would a PR implementing what I describe be considered?

Thank you!

@michaelstingl
Copy link

Anyway - would a PR implementing what I describe be considered?

@pmaier1 @DeepDiver1975 @micbar ?

@T0mWz
Copy link
Contributor

T0mWz commented Oct 12, 2023

@vjt , we have this already for years. You find here the needed code; #182

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

3 participants