-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
JWT Refresh Token #4371
base: main
Are you sure you want to change the base?
JWT Refresh Token #4371
Conversation
4a61779
to
67defe9
Compare
67defe9
to
6aeca93
Compare
6aeca93
to
b27f188
Compare
When discussed with @BlackDex we thought that 7 days might be an appropriate value for the Had some feedback on it, and it might be a bit short, since many actions in the application will not trigger a refresh (reading password is done as "offline"`). Might make sense to raise it to something around 30 days as mentioned in this documentation. |
I agree, lets keep it the same as Bitwarden, and 7 days is a bit short indeed. |
This is a superset of the refresh roll PR, the same logic of changing the device token is used to prevent reusing twice the same
I'm unsure what are the offline logins ? |
I mean offline unlock in some way. But i doubt it. |
A yes when unlocking I don't believe any call is done to the |
f015cc2
to
3b77eb3
Compare
Removed the rolling of the device token since it caused issues when the web client called the refresh token endpoint in parallel. |
3b77eb3
to
0f0f36e
Compare
0f0f36e
to
c48b2e2
Compare
To facilitate review decided to move out the switch to a JWT refresh_token from the sso PR #3899.
Without the SSO logic it's not the most useful still :
refresh_token
(work like an idle timer reset when a new access_token is generated).AuthMethod
in the token (Password
...).