API Authorization

API authorization decides whether an authenticated caller may perform a particular operation on a resource. It should be enforced server-side for each protected request, using a policy that defaults to denial.

API authorization is the process of deciding whether a caller may perform a requested operation on a particular resource. For example, a service might allow a reader to view a report but reserve deletion for an administrator. It answers “may this caller do this?” rather than “who is this caller?”

Authorization normally follows authentication. The API verifies credentials such as a session or access token, then uses the resulting identity and relevant attributes to make an access decision. A request can be authenticated and still be unauthorized.

Policies may be based on roles, explicit permissions, resource ownership, or attributes such as tenant, time, and data classification. A check should consider both the action and the target resource: permission to read one record does not necessarily imply permission to read every record.

Enforce checks on the server for every protected operation, including reads and indirect access paths. Use a default-deny policy, keep checks centralized where practical, and avoid relying on frontend visibility or on a client-supplied role claim that the server has not verified.

HTTP status codes communicate outcomes: `401 Unauthorized` conventionally indicates missing or invalid authentication credentials, while `403 Forbidden` indicates that the request is understood but access is not permitted. APIs may choose `404 Not Found` for a protected resource when hiding its existence is part of the policy.

Key points

• Authentication identifies a caller; authorization decides what the caller may do.
• Evaluate the action and target resource, not just the caller's role.
• Enforce authorization on the server for every protected operation.
• Prefer default-deny policies and test both permitted and denied cases.
• Use 401 for authentication problems and 403 for denied access in the usual case.

Interview questions

What is the difference between authentication and authorization?

Authentication checks credentials and establishes an identity or principal. Authorization evaluates whether that principal may perform a particular action on a resource. A valid login or token does not grant every API operation automatically.

How would you protect an endpoint that returns a user's private records?

I would identify the authenticated principal, the requested operation, and the target resource, then evaluate a server-side policy before returning protected data or performing a change. The policy should default to deny when no rule grants access. I would test both allowed and denied cases, including access to another user's resource.

When should an API return 401 versus 403?

A 401 response generally tells the client that valid authentication credentials are missing or unacceptable. A 403 response means the server refuses the requested operation even though it can process the request. An API can sometimes return 404 instead of 403 to avoid revealing that a protected resource exists.

What is role-based access control, and when might it be insufficient?

RBAC assigns permissions through roles, which makes common job-based policies easier to manage. It can become awkward when access depends on details such as record ownership or tenant, so those conditions may need additional checks or an attribute-based policy. Whichever model is used, the decision should be evaluated against the actual resource and action.