Git Product home page Git Product logo

Comments (4)

michaelbromley avatar michaelbromley commented on May 18, 2024

Related issue: now that the auth operations have been switched from REST calls to GraphQL, errors are no longer being reported correctly.

This seems to be due to the switch from apollo-angular-link-http to apollo-upload-client, which has had the result that the http interceptor no longer gets executed on http calls.

from vendure.

michaelbromley avatar michaelbromley commented on May 18, 2024

Video guide on implementing a refresh token flow for JWT / express: https://www.youtube.com/watch?v=UA0AIkjI85c

Plus the front-end code used to set and update tokens: https://github.com/benawad/gello-world/blob/7_advanced_jwt_auth/src/index.js

from vendure.

michaelbromley avatar michaelbromley commented on May 18, 2024

Why use refresh tokens?

While researching this I had the question of "what is the point of refresh tokens?"

From what I read, the auth token should have a short life (say, 5 - 15 mins) whereas the refresh token has a longer life (say, 1 - 2 weeks). User logs in, then the auth token expires after 5 mins and so the refresh token is checked, validated, and a new auth token is issued. The refresh token is presumably stored in the same fashion as the auth token (localStorage, for example). If an attacker can get the auth token, they can also get the refresh token. So where is the additional security?

Answer from https://security.stackexchange.com/a/119392:

Without frequent refreshing, it is very difficult to remove access rights once they've been granted to a token. If you make the lifetime of a token a week, you will likely need to implement another means to handle, for example, the deletion of a user account, changing of a password (or other event requiring relogin), and a change in access permissions for the user.

From reading that whole thread, it seems that the clear purpose of a refresh token is to:

  1. Provide a way of having long-running user sessions while simultaneously
  2. allowing access to be revoked at short notice.

from vendure.

michaelbromley avatar michaelbromley commented on May 18, 2024

Where to store tokens? localStorage vs sessionStorage vs cookies

https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

Stormpath recommends that you store your JWT in cookies for web applications, because of the additional security they provide, and the simplicity of protecting against CSRF with modern web frameworks. HTML5 Web Storage is vulnerable to XSS, has a larger attack surface area, and can impact all application users on a successful attack.


From https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage

  • Also known as Offline Storage, Web Storage. Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.
  • Use the object sessionStorage instead of localStorage if persistent storage is not needed. sessionStorage object is available only to that window/tab until the window is closed.
  • A single Cross Site Scripting can be used to steal all the data in these objects, so again it's recommended not to store sensitive information in local storage.
  • A single Cross Site Scripting can be used to load malicious data into these objects too, so don't consider objects in these to be trusted.
  • Do not store session identifiers in local storage as the data is always accesible by JavaScript. Cookies can mitigate this risk using the httpOnly flag.

From: https://www.whitehatsec.com/blog/web-storage-security/

Never store sensitive data using Web Storage: Web Storage is not secure storage. It is not “more secure” than cookies because it isn’t transmitted over the wire. It is not encrypted. There is no Secure or HTTP only flag so this is not a place to keep session or other security tokens.

Thoughts

Cookies seem to be the better option but the main issue is CSRF attacks. Angular's HttpClient has built-in CSRF mitigations, see https://angular.io/guide/security#xsrf, so this could be the best way to go. It may also simplify the token transfer/refresh process.

Todo: watch this https://www.youtube.com/watch?v=sHKyMwIK9F0

from vendure.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.