AUTHOREA
Log in Sign Up Browse Preprints

Alec Aivazis edited untitled.html  over 8 years ago

Commit id: f2412965b632eae76655f700ac4aedc9e86e994c

deletions | additions      

       

  • In a single page app, all of the decisions about what view/subview to render occurs on the client and does not require a trip back to the server.
  • This means that the client has to be able to authenticate the currently logged in user and access its data without going back to the server which means it has to be stored locally.
  • JWTs are good because they allow for the client to be responsible for keeping track of the permissions of the currently logged in user.
    • This removes the need for a session store in most cases which dramatically increases scalability
      • No more potential problem of synchronizing the store among processes with separate memory.
  • However JWTs require a secret key to be decrypted which means it can't happen on the frontend with the same key that the server uses, say for its csrf protection
    • A malicious visiter would be able to download the source code compiled on a few different views and look for similar strings. One of them would be the secret key so its easily brute-forcible.
  • Because of this it's clear that we need to have unencrypted way of viewing the local authentication data for use by the application logic
  • Special care needs to be made to prevent someone interacting with the developers console to be able to change the local authentication data in order to gain access to restricted parts of the code by elevating their permissions
    • Another reason not to use global variables
    • This is a different type of network vunerability than the traditional three (target="_blank"  href="http://">xss, target="_blank"  href="http://">csrf, and target="_blank"  href="http://">man in the middle) that arises due to the nature of SPAs
      • Previous paradigms did not have this problem because they could authenticate   every GET request and prevent the user from going somewhere they   shouldn't. 
  • It would be shouldn't
  • Closures to the rescue!
  • Create an anonymous function that is imported wherever the authentication information is used and returns the value given by the server on login.
  • If you wanted to add it to some kind of store that was accessible to the developer console (like redux), it's still  okay to let them modify the data (which we couldn't prevent)  if we had some way of preventing them from doing anything with it afterwards.
    • We afterwards.
    • In that case, we  need some way of comparing it to a known valid state corresponding to the logged in user.

    •  user.
    • That known reference would also be wrapped in a closure to prevent the malicious user from setting the local storage and then changing the value of the comparison to match the new data.