19.1. Introduction to Authentication¶
We log into many, many websites every day. The process has become so routine that we expect it to work flawlessly every time. How surprised would you be if you logged into a website and saw a different user’s account info? What if you entered the wrong password and were still let in? What we have come to expect as routine is anything but when we consider the code needed to make it happen.
19.1.1. What Is Authentication?¶
Authentication is the process of determining a user’s identity. In other words, are they who they say they are?
This is typically done by asking a user to provide a secret piece of data, which theoretically only they should know. Passwords are the most commonly used secrets, but there are others such as RSA keys and physical authentication tokens. Authentication relies on the ability of the user to keep their secret data, well, secret. If we are given a user’s secret data, we assume that only one person could have provided it.
A related, but different, concept is authorization. Authorization is the process of determining if a user is allowed to carry out a specific action.
I can share a Google doc with my coworker with read-only permission. They are then authorized to view the document, but not to make changes.
Most applications that store personal data use authentication and authorization together. In this book, however, we will only discuss authentication.
19.1.2. Flow for Simple Authentication¶
Using authentication allows a web application to restrict access to certain pages to known users only. The simplest form of authentication treats all users the same. If a user is signed in, then they are allowed to view all restricted pages. Otherwise, they may not view any. With simple authentication, it is not possible to restrict a page to some users while allowing access by others.
Simple authentication requires that for every request, the application answers two questions before the request is handled by a controller:
Is the user asking for a restricted page?
If so, do we know who they are?
The answers to these questions determine whether or not the user is allowed to view the page.
The logical flow of simple authentication looks like this:
19.1.3. A Note On Authentication In Spring¶
Before we proceed, we want to point out something important about authentication in Spring. Spring contains a sub-project, Spring Security, that provides extensive support for authentication and authorization. In addition to supporting simple authentication, Spring Security also supports more sophisticated authorization flows/processes like OAuth 2. Professional developers working with Spring nearly always use Spring Security.
In this book, we are explicitly not introducing Spring Security for two reasons:
The project handles many aspects of the authentication process for you. This hides many of the steps that are important to understand as you learn about authentication.
Setting up Spring Security is fairly complicated, and requires concepts that are beyond the scope of this course.
That said, the authentication approach outlined in this chapter is sufficient for use in your personal projects. When you begin working with a team on professional applications, a senior developer will likely be on hand to help with authentication setup.
19.1.4. Check Your Understanding¶
Which of the following are true:
A session is stored on the server.
A session is stored in the browser.
A cookie is stored on the server.
A cookie is stored in the browser.
What is the difference between authentication and authorization?
Authentication handles user permissions, authorization handles user restrictions.
Authentication handles user identity, authorization handles user permissions.
There is no difference, they are synonymous terms.
User authorization can be changed in a request, authentication cannot.