Open-event-server: API implementation for Token Refresh

[James7777]

Is your feature request related to a problem? Please describe.

There is currently an issue in both apps(attendee and organizer) when the token expires, the user is asked to re-login, this is not good for user experience.

Describe the solution you'd like

Token refresh should happen under the hood using the existing expired token.

Describe alternatives you've considered

Two options;

• automatically refreshing token using a background service like WorkManager
• automatically using authenticator to capture 401 errors, refresh token synchronously and retry failed requests.

Additional context

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label feature to this issue, with a confidence of 0.90. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[iamareebjamal]

For server, it doesn't matter the approach client takes. That detail is to be discussed on client repo. For now, long life refresh tokens are to be granted if the request payload contains remember-me as true. If the client is mobile, it'll be granted the refresh token in response JSON itself. In case of web, it'll be sent using HttpOnly and secure cookie to protect from XSS attacks. This will still be vulnerable to CSRF attacks, so need to think about how to handle that on web. Maybe API based CSRF token, but I don't know how feasible that will be. But can still be first implemented for mobile.

An endpoint for refreshing the token is to be implemented. Which will accept the refresh token either from JSON or cookie.

An endpoint for blacklisting refresh tokens is to be implemented in order for a user to restrict login from leaked tokens. We'll not store the blacklisted tokens, but simply add a one to one mapping of user to blacklist-time when user asks to blacklist the tokens. Any refresh token or auth token created before that time will be considered invalid. And thus user will be logged out of all the previous devices as well. This will act as a double security feature, by limiting the attack due to leaked credentials and also logging out the user from all persistent sessions.

[James7777]

Sounds like a good plan, thanks iamareebjamal.
With this feature implemented especially for mobile clients will improve security and better user experience, is this something that can be implemented in the next 2-3 months.
In my tests, I have attempted to see how it can be implemented using a request authenticator in the Network module of the attendee app but getting an injection cycle issue mainly caused by AuthApi interface.
Thanks

[iamareebjamal]

Will be done within fortnight hopefully

[James7777]

Thank you so much guys for this project

[James7777]

Hi,
Unfortunately I cant assign issues.
Thanks
Caleb

On Fri, 2 Aug 2019 at 05:41, Ashutosh Hathidara [e-mail]
wrote:

@James7777 https://github.com/James7777 and @iamareebjamal
https://github.com/iamareebjamal, I want to work on this issue, Please
assign me the task. I will do it within 3 days.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fossasia/open-event-server/issues/6168?email_source=notifications&email_token=AB7AEYVL3OLBJTIBIDIJBBLQCO3IDA5CNFSM4H7OMLHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3MR3ZI#issuecomment-517545445,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB7AEYTZF6OWYVBKD6LHQVLQCO3IDANCNFSM4H7OMLHA
.