Authentication in the World of Front-End Frameworks

Question

my question is regarding login in today’s front end world:

in the old ways of server side rendering - i would authenticate a user login in the backend and render an entire html page that suits the user that logged in.

but now with front end frameworks - i give the user all the possible pages the first time he enters the website, and then renders the right page for him in his browser.

as far as i understand this now - to login a user in a frontend framework, i need to save a variable indicating he is authenticated (and perhaps even his role in case of an admin) in the localStorage, and this way when i’m building pages i just need to ask if this variable is in localStorage to know if the user is logged in, and if his role is admin, and in case both are true i show him all the admin functionalities

however, this means that if i was a hacker - all i needed to do is manually add this variable to my localStorage and then i’ll see the entire admin functionalities.

which brings me to my question - is there a better way to perform login authentication in today’s frontend world? or am i bound to let the hacker see all the admin functionalities, and can only protect them from being used by unauthorized user only in the backend?

Answer 1

Although you may serve pages specific to authenticated users as part of a single page application, you wouldn't provide the data. So a user could potentially hack the site to view an admin only page and get the layout but the content would be missing.

A separate request would be made to the server for the protected data and the secure content would only be returned if the user has the required permissions. This is then slotted into the page for example using Ajax.

There are lots of ways for the server to check if the client is authenticated. The simplest would be to pass the username and password with every request. The variable in local storage that you mention could store the username and password so it can be referenced with each HTTP request. In reality you wouldn't do that because it's not very secure. More likely you will be sending some sort of token that was returned by the server on log in and has been hashed and/or encrypted. If the user was to modify it, the server would know and would render it invalid, and refuse to send the requested content.

Have a look at some of the authentication strategies listed in Passport. There are numerous libraries that do the same but passport has a good selection for your reference.

If you really want to stop an unauthorised user even seeing the admin options you should not render the html for that as part of the main application. A separate request should be made to return that HTML when required. Clicking the "admin" button would make a request for the admin page. The server would only return the relevant view if the user has the required permissions (exactly like in traditional multi page applications). The difference would be how the client application handles that. Now we would insert it into the current page rather than refreshing the whole thing.

Answer 2

The variable you mention is normally the JWT token. A token that you send to the server on each request (you can use an Angular interceptor to do this) and validate on the server. You can read more about them here: https://jwt.io/introduction/

As for the user information (name, roles etc), I'd keep that in memory instead of local storage.

As for the your admin section question, yes, you always assume a hacker sees all your front end. But since you validate actual actions on the server side, then all he can do is view it.

You could split your front end in 2 code bases and have stricter access to the admin one, but then an admin could theoretically save your front end assets and leak it to a hacker. So you get all the hassle of 2 code bases for not much more protection.

Bottom line, just protect the backend.