Authentication vs Authorization (AuthN vs AuthZ)

Authentication (AuthN) verifies who a user or service is, while authorization (AuthZ) decides what that verified identity is allowed to do. In a Java backend, these are separate concerns even though frameworks often handle them together.

Authentication establishes identity by validating credentials or another identity proof, such as a password, session cookie, API key, or token. A successful authentication typically produces an identity or security principal that the application can use for later decisions.

Authorization evaluates whether that identity can perform a requested operation on a particular resource. The decision may depend on roles, permissions, ownership, scopes, or other application rules. For example, an authenticated user might be allowed to read an account but not delete it.

A typical request flow is: authenticate the caller, establish the principal, then authorize the requested action. Authentication failure commonly results in `401 Unauthorized`, while a caller who is authenticated but lacks permission commonly receives `403 Forbidden`.

In Java applications, frameworks such as Spring Security can integrate both stages. A developer should still understand the distinction because correct configuration requires knowing whether a rule concerns identity verification or access control.

Key points

• Authentication answers: "Who are you?"
• Authorization answers: "What may you do?"
• Authentication normally happens before authorization.
• `401` commonly indicates missing or invalid authentication; `403` commonly indicates insufficient permission.
• Roles, authorities, scopes, and ownership rules are authorization mechanisms.

Interview questions

When should an API return 401 versus 403?

A `401` response is generally appropriate when the request does not contain acceptable authentication credentials or the supplied credentials cannot establish an authenticated identity. A `403` response is generally appropriate when the caller is authenticated but is not allowed to perform the requested operation. The exact behavior can depend on the API's authentication scheme and security design. The important distinction is authentication failure versus authorization failure.

What is the difference between authentication and authorization?

Authentication verifies the identity of a caller. Authorization determines whether that identified caller may perform a particular action or access a resource. Authentication can establish a principal, while authorization evaluates permissions associated with that principal. In a typical web request, authentication occurs before authorization.

What happens after a user successfully authenticates?

The application establishes an identity for the caller, often represented by a security principal. Subsequent authorization checks can use information associated with that identity, such as roles or authorities. Authentication itself does not grant unrestricted access. Each protected operation still needs an appropriate authorization decision.

How would you implement role-based authorization in a Java backend?

I would first authenticate the request and establish the caller's identity and authorities. Then I would enforce authorization at the appropriate application or security boundary, mapping roles such as `ADMIN` to permitted operations. With Spring Security, authorization rules can be configured at the request or method level. For sensitive operations, I would also consider resource ownership and more specific permissions instead of relying solely on broad roles.

Why is client-side authorization not sufficient?

Client-side checks can improve user experience by hiding controls the user cannot use, but the client cannot be trusted to enforce security. A malicious caller can bypass the UI and send requests directly to the backend. Therefore, the server must independently authenticate requests and enforce authorization for protected operations. Client-side restrictions should be treated as presentation logic rather than the security boundary.