OK, so I told you at the end of the last chapter that we’re going to set up a login form. But you have one more thing to learn before we start. You need to learn about different ways to set up login forms on web applications.
When you go to your bank’s website and log in, you assume that you are the only one with access to your account information, right? You wouldn’t want someone else to be able to log in as you or find a way to use your account.
When you log into the bank, the web application authenticates that you are you. 😄 When you look at a page with your account - for example, your bank statements - the application is authorizing you to look at a particular page. These two features - authentication and authorization - are at the heart of Spring Security. If you can keep this process secure, you’ve won half the battle.
In security, there is a term called access control, and it essentially controls access to a web application that requires a login mechanism. Access control comes in two steps. Can you guess what those are?
Authentication and authorization?
Yes! We’ll be using Spring Security to implement access control into your Spring Boot app, but first, let’s dive into the details of authentication and authorization.
Define Authentication
When you go to an office building for a large corporation, you typically see guards checking Ids or a machine that scans your badge. This is a physical access control feature that ensures that you can prove whom you are before going inside.
In web applications, how do you think you authenticate to the site and prove that you are who you are?
By logging in with your password?
Right! Typically in web applications, you authenticate by logging in with a username and password. A username identifies who you are. The password is something only you know. This is called single-factor authentication because you only have to know one way (the password) to prove who you are.
Sometimes you provide additional elements, like biometrics, a physical token, or a badge. This is called multi-factor authentication because you have to (1) know your password and (2) have something else to prove you are whom you say you are.
Once you are logged in, the web application already authenticated you because you have proven that you are you. Here comes the next step: authorization. 😁
Choose From Multiple Types of Authentication
Let’s talk about different kinds of authentication. You learned about single-factor authentication where a user logs in with a password. You also learned about multi-factor authentication, where a user can use multiple items to prove identity. There are also different types of ways your web browser handles your authentication:
Session-Based Authentication
In session-based authentication, users first log in using their credentials. When they are successful, they have authenticated themselves and have started a session. A session is the time between when the user logs in and logs out. The server saves the user’s session information and sends a copy of it in a small file (a cookie), also saved in the user’s browser. Typically, this information may include the user’s credentials, how long the session lasts, and a session Id number. Every time the user sends a request through the web application, the server checks with the cookie to ensure the session credentials match those on the server and are still valid.
Token-Based Authentication
In token-based authentication, the user authenticates to the server, and the server sends the session information in a small file (a token) to save only on the user’s browser or local computer. A token is similar to a cookie in function, but there are some significant differences. With session-based authentication with a cookie, the user’s credentials are saved on the server’s database as well as the user’s browser. In token-based authentication, a JSON Web Token (JWT) has the information needed to validate the user, so the session information does not need to be saved on the server, making it stateless.
So what exactly is this JSON Web Token?
JSON stands for JavaScript Object Notation. The JSON Web Token is a little JavaScript object that encrypts and transmits your authentication information. It validates that a user is authenticated because it holds encrypted information only the authorization server can understand. It makes things more efficient and secure than using a cookie, so most Java web applications are based on JWT.
Understand Authorization
To understand the difference between authentication and authorization, let’s go back to the office building analogy. Say you’ve already made it inside after authentication. You are now in the building and would like to go to your department. Your office is on the fifth floor with all the other developers. You go to the elevator and hit the button for the fifth floor, but it doesn’t light up. 😕
You then remember you have to scan in your badge before you can select your floor. You see, are authenticated, but now there are checks inside the building to see if you are authorized to access other parts of the building.
Authorization happens after authentication. The web application takes another measure to see if you are allowed access to certain parts of the web application.
Applied to web applications, we typically have user and administrator scenario. When an administrator is authenticated into a site, the web application allows that person a different set of rights than a regular user. This is where authorization comes in.
It’s not just people that need authentication and authorization. Sometimes you are protecting a network, application, networked device, computer, or server. In these cases, you see processes (computer updates run in the background with administrator credentials), resources (your computer wants to access a file in a server or get on a network), and systems (servers, computers, network devices, etc.) that need to authenticate and be authorized.
What would this look like in a real situation?
Imagine that the sales department in a company has a computer that’s not locked down. They handle transactions with outside entities, so their computers and network are not as secure as the rest of the departments in the company. These computers are only allowed in the sales department section of the company’s network. So, the network is set up so that when the computer authenticates into the network, it is only authorized to be used in the sales department network. The computer cannot be used in the more secure parts of the company’s network.
Let’s go over what you’ve learned about different ways people get authenticated and authorized on web app login forms.
Let’s Recap!
Authentication checks to make sure that the user knows the right information to prove they are who they say they are.
Authorization makes sure that the authenticated users only go to the pages they are allowed to see. Two types of authentication are:
Session-based authentication uses cookies to store information about the user’s session. The cookies are stored in the user’s browser and on the authorization server’s database.
Token-based authentication uses a JWT sent from the authorization server. The JWT is used to validate that the user is logged in and can be stored in the browser, but is best stored in a secured token on the browser.
Let’s apply what you’ve learned in this chapter and create a default Spring Security login page in the next chapter. We’ll also configure a simple Spring Security filter chain to define its security configuration. Let’s get to coding!
Further Reading
To learn more about different authentication methods, check out this article.
