SPA Authentication in MEAN Stack
In our previous section, we successfully created the users. Now, what does logging a user actually mean, how do we store that information, and how do we then use it to allow a user to create a post or forbid it. This actually works differently for Single Page Applications than it works for normal full-stack applications. In single-page applications like our angular app, we have our back-end with some routes, products, and the product that is not our app here, that is an app we might be building.
We typically send requests through the HTTP client, as we learned. Some of these routes might be protected. For example, we might be able to get a list of products, but we can’t create a new product, at least not if we are not authenticated.
In the traditional full-stack app, we would have used a session for this. So, if a user logs in with his credentials, we would create a session on the server and return the session ID in a cookie to that client, so to the browser, store it there and for every future request, we would automatically send that cookie and validate it on the server and grant access if the cookie ID matches a valid session on our server. This is how it works in a nutshell.
This doesn’t work for single page application because the Single Page Application backends, our API here is stateless. So, it is not connected to the front-end app. It doesn’t care about that app. That is why we have two separate servers, we have a node and our angular server, and we manage them in the same project, but they are totally separated from a logical perspective. We could connect any app to our rest API. We could connect a mobile app. So the angular app is decoupled from our node backend when it comes to this, it just sends requests to these URLs, but our server doesn’t store any information about the app. Therefore, the server also doesn’t store any sessions.
So, we have to find a different way of storing that authentication information, and we will typically do that with a JSON Web Token. We could say, it is just like a package of information hashed into one long string generated on the server upon successful login. That token is sent back to the browser where we can store it in our angular app, in a cookie or in the local storage, an api we can access through our browser.
This token is then attached to all future requests as part of the URL or as a header, and that token can’t be faked. It is hashed in a way that is impossible to break. We can unhash it. We can look into it; that is fine, but if we edit one character in the data that is part of the token, the entire hash will change. So we can’t fake that, we can’t change it, and we can’t guess it. Only the server can validate that this token is valid because the server was the one created that token. Only the server knows the exact algorithm.
So, we send that token with any future request, and then that actually fives us access because the server can validate that token and only request that has a valid token is allowed access. Other requests are rejected.
This is how we typically handle authentication in Single Page Application, and this is how we will handle it in this module.
We will do all these things practically in the next section.