Once authenticated, a user will be able to access the application. However, it doesn't mean the user can do anything at will. The access will be limited to only those resources that the user has been authorized for. For example, a user can edit his/her own personal information and is forbidden to modify another user's. The following figure shows a user trying to access payment information inside an admin module and getting an Access Denied error, or forbidden error, usually sent back to the client side with the HTTP status 403:

There are two types of authorization. One is role-based authorization, for example, as long as the user has the admin role, he/she will be able to access the /admin/payments resource. This is a coarse-grained authorization since it only has the ability to control access at the resource type level, even though you can add a privilege, such as READ, WRITE, or DELETE. Another type of authorization is through an access control list (ACL), which is a list of permissions attached to a piece of data, as well as a list of users who have been granted access to that piece of data. In this way, users can have fine-grained authorization. For example, with ACL, you can specify that an admin can only view the payment of User A, but can manage the refund to User B. In general, role-based authorization is easier to maintain and manage, while ACL-based requires extra effort in maintaining the list and extra steps to determine if a user has the authorization to access a resource or not. 

Sometimes, the authorization you want to perform isn't simply either a completely role-based approach or ACL-based approach. For example, as mentioned earlier, in TaskAgile, we only allow users to access cards of the boards that they have joined. So, if you are not a member of that board, you shouldn't be able to view it. Board member seems to be a role. However, it isn't really a role since you will have to join a board to be a board member. The membership is related to a specific board. On the other hand, it feels like a little bit of ACL. However, we won't define an access control list because we have already stored the membership information in board_member. (If you do not remember this, you might want to check the data modeling in Chapter 5, Data Modeling - Designing the Foundation of the Application). Therefore, in TaskAgile, we will create a custom authorization mechanism based on Spring's EL, which we will talk about later in this chapter.