To lay the ground work for this course, let's take a look at how authentication is done in what I'll call a traditional web app. A traditional web app has a lot of definitions. I'll think of it as an application where the user has to refresh the page to get some new data or to send data to the server. If the user comes to your website or your web app and they want to submit some data to be saved in the database, when they do that to get a response back, they actually have to go through a full page refresh. Likewise, when they want to get some new data from the server, they actually have to refresh the page to get that data.
We're probably all quite familiar with this. This is kind of how the web was built. You have to send a request and refresh the page to get new stuff. As you probably know, since you're working with Angular, it's a framework for building what we call single page apps. The single page app, of course, is one where you don't have to go through that full page refresh to submit data or to get new data. Single page apps actually send and receive data through XHR requests which happen behind the scenes. What we get with that ultimately is the feel of a native desktop application which makes for a much nicer user experience. That's probably why you're building applications with Angular. You want to have that snappy fluid desktop-like feel.
Back to authentication. How does it actually happen in a traditional web app? Typically it looks like this. The user will come to your application. They will log in with their credentials, their user name and their password. Those credentials get submitted and sent to the server where they're checked against a database. If everything matches up, a session gets created on the backend (on the server) for that user. The session is this piece of data that the server can use to know that the user is authenticated. Now when the user needs to navigate to another spot in the application, let's say they go to their profile page next (and that happens through a round trip request), the server is able to know that the user is authenticated.
This raises the question: how does the server actually know who it is that's making these requests for data. It would seem that the server needs some way to actually be able to verify that the user who has sent the request is the user that's actually authenticated.
This is where cookies come in. You might be familiar with cookies. These are the small pieces of data that get saved in the user's browser. Cookies actually get automatically sent to the server on every request to it. Since cookies hold pieces of information, what we can do is have that cookie store an identifier for the user. This is typically what happens. When the user's authentication is valid, the response that comes back to them contains a cookie that gets saved. This cookie has an identifier for that user. Then, the cookie automatically gets sent to the server whenever the user navigates to another page. It's the cookie's information that gets verified against the session that tells the server whether or not that user is who they say they are. The server is then able to know that the user should still be authenticated when that session exists on it. Because this happens automatically, the user doesn't need to send their credentials every time and their credentials don't need to be checked against the database every time they make a request, or at least not until the cookie has expired.
This method of authentication works pretty well for traditional web apps (for those that require the full page refresh), but there are some limitations to using cookies and sessions together for modern applications like the ones that we build with AngularJS. We'll talk about what those limitations are and how to get around them in the next lecture.