Spring Security operates on two fundamental concepts--authentication and authorization.

These two concepts can be described as follows:

• Authentication: This defines who you are
• Authorization: This defines what you are allowed to do

The first step in any security system is to confirm the user's identify. This often involves a username and a password, but these credentialed bits can be stored in many different systems, including relational databases, directory servers, certificates, and other things. However, these are implementation details that surround verifying someone's identity. Until we know who you are, we can't make any determination.

HTTP Basic, HTTP FORM, and other forms of authentication are supported by Spring Security. Right now, we are using HTTP Basic on the frontend as well as the cross-service calls, given that it's the only version currently supported with Reactive Spring Security.

The second step in any security system is to decide what the user is authorized to do. Both a teller and a vice president at a bank can be authenticated, but they will certainly have differing permissions on what they are each allowed to do. The teller may be granted permission to open his assigned cash drawer, while the vice president may be authorized to open her customer's account.

With the SecurityConfig code given earlier, our chat microservice has instituted authentication, which is linked to the session. However, it also chose a very simple authorization strategy: anyone that is authenticated can do anything. Since the chat microservice does little more than communicate via a WebSocket, that is fine. In the next section, we'll see a different policy, where certain operations are restricted to a subset of users.