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

Delete JWT on Logout #412

Closed
1 of 4 tasks
lemazza opened this issue Jun 6, 2020 · 3 comments · Fixed by #1583
Closed
1 of 4 tasks

Delete JWT on Logout #412

lemazza opened this issue Jun 6, 2020 · 3 comments · Fixed by #1583
Assignees
Labels
bug Release Note: Shows as Error Correction features: Security Testing level: medium priority: SHOULD HAVE role: back-end Node/Express Development Task role: front-end Front End Developer
Milestone

Comments

@lemazza
Copy link
Contributor

lemazza commented Jun 6, 2020

Overview

Investigate best practice for removing JWT cookie on Logout. It currently remains after logging out, which could create security vulnerability.

Action Items

  • RESEARCH: Read on best practice for storing jwt info. We currently use httpOnly Cookie. Is localStorage better? Is httpOnly necessary?

JWT Storage Best Practices

Use cookies

What is HttpOnly prop of cookie

  • In short, the HttpOnly flag makes cookies inaccessible to client-side scripts, like JavaScript. Those cookies can only be edited by a server that processes the request.
  • So long as you are not running javascript to collect site traffic data or analytics, then you can use HttpOnly to provide an extra layer of protection for your website. 
  • HttpOnly tags are especially useful on websites that — for one reason or another — have not yet adopted the HTTPS protocol.
  • When not to use HttpOnly
    • Using javascript for analytics
    • Using javascript for page state. If your website's page state depends on javascript to interpret and modify your cookie values, this site type of site architecture may not work with HttpOnly and could leave the site open to cross-site request forgeries (CSRFs). In cases like this, you should leave out the HttpOnly flag and simply use the secure flag with the HTTPS protocol.
  • A cookie with the HttpOnly attribute is inaccessible to the JavaScript Document.cookie API; it's only sent to the server.

Cookies vs Local Storage

Cookies
  • Cookies in JavaScript are used to read from and store small data related to the user on the browser.
  • Local Storage allows you to also read from and store data related to the user on the browser using JavaScript's Storage API.
  • An example of using cookies is storing the user's authentication token when they are logged in. The server needs to have access to that cookie to authenticate the user in later requests and retrieve data or process actions based on who the user is.
  • Cookies on the client-side (the browser) are natively accessed with document.cookies. When you store cookies on the browser, you can make them specific to a path in a domain name and you can add an expiry date for them.
    • Except HttpOnly flag
Local Storage
  • Local Storage is used to read and write data in the browser's storage. The data is persistent and has no expiry date.
  • An example of using local storage is storing the user's color mode preference (light or dark mode). This piece of information is generally not necessary for the server to know, and is used to ensure that the user's preference is reflected on the website.
The Difference
  • The server can access the client's cookies but not the data stored in the client's storage.
  • So, in use cases where it's important for the server to have access to a set of data, you should use cookies.
  • Cookies should not be used to store large pieces of data. For example, if you want to store the user's details in the browser then it's best to store them in the local storage.
Which to use
  • If you need to store data that is accessible for both the server and the client, use cookies. Otherwise, use local storage.
  • If you need to store larger data, use local storage.
  • If you need to store data that does not expire, use local storage.
  • If you need easy-to-use methods to access and modify the data stored on the client, use local storage.

- [ ] APPLY: I anticipate the solution will either be:
- converting the cookie to not httpOnly and deleting it from client on logout.
- or creating a server endpoint to remove the cookie

Technical Solution

  • Understand Login and Logout flow
    • ..routes/account.routes
    • Here we have login and logout routes.
    • Note that I am able to log to console during login, but logout route is not hit on logout.
      • Is logout handled another way? Possibly by the account.controller's login method?
  • As there is no way to delete a jwt, we need to set the expiration to a date shortly after logout. Currently, we set this expiration to 12 hours at login. At logout, we can get the token from the request, and then set the token with a new expiration dateTime.
  • UPDATE DOCUMENTATION: update register.md which currently indicates jwt should be deleted from client.

Previous related issues:

@vincentdang
Copy link
Member

Progress: Just read some of it.
Blockers: Need to read more.
Availability: This weekend and next week from M-F during evenings.
ETA: Give me at least two weeks.

@vincentdang
Copy link
Member

Progress: Just read some more of it.
Blockers: Need to know more about how tdm-calculator website operates (in terms of access/storage/security).
Availability: This weekend and next week from M-F during evenings.
ETA: Give me at least two weeks.

@vincentdang
Copy link
Member

Progress: Just read some more of it.
Blockers: Need to know more about how tdm-calculator website operates (in terms of access/storage/security). Need to ask experts.
Availability: This weekend and next week from M-F during evenings.
ETA: unknown.

@ExperimentsInHonesty ExperimentsInHonesty moved this to On Dev - not yet pushed to Prod in P: TDM: project board Jun 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Release Note: Shows as Error Correction features: Security Testing level: medium priority: SHOULD HAVE role: back-end Node/Express Development Task role: front-end Front End Developer
Projects
Status: Released
Development

Successfully merging a pull request may close this issue.

9 participants