Security Authorization

Security authorization determines what an authenticated user or system is allowed to access or perform. In a Java backend, it is commonly enforced with roles, authorities, permissions, and access rules.

Authentication answers “who are you?”, while authorization answers “what are you allowed to do?”. A request can be successfully authenticated and still be rejected because the authenticated principal lacks the required permission.

Authorization rules should be enforced on the server, close to the protected resource or operation. In Java applications, frameworks such as Spring Security can apply rules to HTTP endpoints and methods using roles or authorities.

A role is a coarse-grained grouping such as `ADMIN` or `USER`; an authority or permission can represent a more specific capability such as `ORDER_READ` or `ORDER_DELETE`. The appropriate granularity depends on the application's requirements.

Authorization should also consider the resource being accessed. For example, checking that a user has `ORDER_READ` does not necessarily prove that the user may read every order; an additional ownership or tenant check may be required.

Key points

Interview questions

How would you implement authorization in a Java backend?

I would define the application's roles or authorities and enforce them on protected endpoints or service methods. With Spring Security, authorization can be expressed through HTTP security rules or method-level annotations. The backend should obtain the authenticated principal from the security context rather than trusting client-supplied permission data. For sensitive resources, I would also perform ownership or tenant checks.

What is the difference between authentication and authorization?

Authentication verifies the identity of a principal, such as a user. Authorization decides whether that authenticated principal is permitted to perform a particular action. For example, logging in may authenticate a user, while a permission check determines whether they can delete an order. Both are security controls, but they solve different problems.

Why is hiding a button in the frontend not sufficient authorization?

Frontend controls improve user experience but are not a security boundary because a client can be modified or bypassed. An attacker can call the backend endpoint directly without using the application's interface. Therefore, the server must independently verify the principal's permissions before performing the operation. The frontend may hide unavailable actions, but the backend remains authoritative.

What is the difference between role checks and resource-level authorization?

A role check answers whether a principal belongs to a permitted category, such as `ADMIN`. Resource-level authorization evaluates whether that principal may access a specific object, often using ownership, tenant membership, or another policy attribute. An `ORDER_READ` authority, for example, may allow reading orders generally while a separate check restricts access to orders belonging to the user's tenant. Combining these checks prevents overly broad access.