In this short blog post we’ll be going over the five components that make the core of Security in Spring Framework. They are authentication, authorization, principal, granted authority and roles. Some of these terms (or all of them) might be already familiar to you but just in case you missed some of them, here is a quick overview.

Let’s say you are packing your stuff and leaving for a nice two-week trip to a lovely resort somewhere in the Swiss Alps. Besides all the things you might need to bring with you, one is key in order to get into a foreign country – quite literally. You need your passport as a proof of your identity and for a safe passage into the wonders of another country. This is your authentication in the real world. In the world of Spring Framework, you also need a proof of identity, but in a different way.
In order to prove your identity to a Spring app and make it let you explore its business logic, you will need to present a password, a PIN code, an answer to a security question, or any other means of proving that your access to this app is legitimate. The “security personnel” inside the Spring app will try to match your information to its database of security data and let you in if there is a clear match. This answers to a simple question of who you are and are you allowed to be anywhere near the app in the first place.

Now that you passed the “border control” with a valid passport, you need to follow certain rules and regulations that the space you are currently in requires of you. You are now entering a new zone that might let you into some areas and restrict your access to others. You are for sure allowed to walk on a pedestrian sidewalk in any of the public streets but you cannot easily march into a high-level top-secret military compound.
The same applies to a Spring Application. The regulation of such rules falls into the authorization category which answers to the question of what are you allowed and not allowed to do within the app. You might be completely free to roam around the app endpoints that get you the latest stock market information but cannot approach the POST or PUT endpoint that change those information in the same manner.
As in the order of our little story here, it is important to conclude that in order to get authorized, you need to get authenticated first. That is the order of security layers in Spring applications as well.

Now, imagine that foreign citizens need to show a passport in every restaurant, market or museum they enter. It would be a huge pain, wouldn’t it? Luckily for us, we don’t need to do it because our data is already in the system at our entry point of the country we got in. Once we are in, we are free to trade and eat and visit landmarks all around.
Similar is the state of Spring Security. Once inside, the user is stored in a single entity called Principal. Here, Spring app stored all the data about the logged in user, its authentication, authorization and additional data that we will mention in just a minute. Principal object is accessible if needed in the security filter of Spring application and can be used to check whether the currently logged in user can do a certain action or not. To be more precise, that is done through the remaining two components of Spring Security: Granted Authorithy and Roles.

Countries often give some citizens greater privileges than others. It is a necessity in order to keep the law and order on the streets. Domestic citizens only hold a basic set of rights, foreign citizens have even more reduced rights and law enforcement officers might have a larger set of rights than both of these categories do.
We observe the same behavior in Spring application Security as well. Some logged in users can access more endpoints and methods within the app than others. This is how authorization is being done on a more finely grained level – all users that get authenticated do not have the same level of authorization. Some are granted authority to do more stuff than others. This information is stored within the Principal object, in an array list named Granted Authorities, and serves as a central spot to decide whether a user that is properly authenticated can access a certain part of the application or not.

Along with the different rights, citizens have different roles within the society as well. Some are students, some are civil rights activists, some are entrepreneurs and some are acting as representatives of the state itself. Some hold more than one role at the time. 
These real life examples hold true within the Spring Security as well. Alongside the Granted Authority part of the Principal, logged in users can be assigned different Roles which can also allow or prevent the user from getting access to certain parts of the application. A combination of roles can grant higher authorization than assigning only one, so a user can have more than one role at a time. This extends the rights of a user or shrinks them if roles are removed at a certain time. 

It is fairly easy to grasp the main 5 concepts of Spring Security. First (authentication) makes sure that the user that is trying to get access to the application is at the right spot. Second (authorization) helps guide the user on what endpoint or services of the application it can access. Third (principal) is an object within the Spring Security that holds all this information for the developer and helps make the right decision on user’s rights and privileges. The fourth (granted authority) and fifth (roles) work closely together to ensure that the user can access only those parts of the application that he/she is entitled to.
A combination of these five components makes the Spring Security function well and hold back any unwanted access to Spring application features.