Authentication vs Authorization

Authentication establishes who a caller is, while authorization determines what that caller is allowed to do. Backend systems typically authenticate a request before evaluating its permissions.

Authentication answers “Who are you?” It verifies an identity using evidence such as a password, API key, session cookie, or token. A successful authentication step establishes an identity or principal that later security checks can use.

Authorization answers “What may you do?” It evaluates the authenticated principal against rules such as roles, permissions, resource ownership, or scopes. For example, a user might be authenticated successfully but still be forbidden from deleting another user’s account.

In a Python web service, authentication is commonly implemented in middleware, dependencies, or request-processing code that validates credentials and attaches the resulting identity to the request context. Authorization can then check that identity against the requested operation and resource.

These concepts should remain separate because a valid identity does not automatically grant access to every operation. A useful HTTP mapping is `401 Unauthorized` for missing or invalid authentication credentials and `403 Forbidden` when the server understands the caller but denies the requested action.

Key points

Interview questions

What is the difference between authentication and authorization?

Authentication verifies the identity of the caller. Authorization decides what that authenticated identity is allowed to access or change. For example, logging in with valid credentials authenticates a user, while checking whether that user can delete a resource is authorization. The two checks are related but should be treated as separate security concerns.

Where would you implement authentication and authorization in a Python backend?

Authentication can be centralized in middleware, request dependencies, or another reusable request layer that validates credentials and establishes the caller identity. Authorization can be applied after authentication, either through reusable permission checks or policy components. Resource-specific checks should also verify ownership or other attributes when necessary. Centralizing common checks reduces inconsistent security behavior across endpoints.

Why isn't possession of a valid access token enough to authorize every request?

A valid access token can establish that the request is associated with a particular principal, but authorization depends on what that principal is permitted to do. The token may contain scopes, roles, or other claims, but the application still needs to apply those claims to the requested operation and resource. Some permissions also depend on current server-side state, such as resource ownership. Therefore, token validation and authorization policy evaluation are distinct steps.

What should an API generally return for failed authentication versus denied authorization?

An API commonly uses HTTP `401 Unauthorized` when authentication credentials are missing, invalid, or otherwise insufficient to establish a valid identity. It commonly uses `403 Forbidden` when the request is understood and the caller is authenticated but lacks permission for the requested action. Exact API behavior can vary by protocol and security design, but the distinction is useful for designing consistent HTTP APIs. Error responses should also avoid unnecessarily exposing sensitive security information.