Authentication and authorization are routinely bundled together as 'auth'. Define each precisely, explain why they are kept as separate concerns in a system's design, and name the failure that appears when they are conflated.
answer
- who are you vs what may you do
- once per credential vs every request
- gateway authenticates, resource owner authorizes
- impersonation vs escalation
- 401 unauthenticated / 403 unauthorized
basics
~20 sAuthentication establishes who the principal is, from evidence, with some level of confidence. Authorization decides whether that principal may perform this action on this resource, in this context. Conflating them produces 'logged in, therefore allowed' - the most common access-control bug.
solid answer
~50 sAuthentication answers 'who is this' - a claim of identity plus evidence for it, evaluated when credentials are presented, producing a principal and an assurance level. Authorization answers 'may this principal do this' - a decision function over subject, action, resource and context, evaluated on every access. They are separated because they differ on every axis: different inputs (credentials versus domain state), different frequency (once per credential presentation versus once per request), different placement (an edge component can authenticate; only code that knows the resource can authorize), and different failure modes (impersonation versus privilege escalation). The conflation failure is 'authenticated therefore allowed': the system verifies identity carefully and then acts on any request that arrives with a valid session. The mirror failure is treating an authorization construct as identity - a shared service account used by many humans satisfies policy while destroying attribution. Protocols encode the split: HTTP 401 means unauthenticated, HTTP 403 means authenticated but not permitted.
go deeper
Give crisp definitions plus one concrete example of each and the 'logged in therefore allowed' failure.
Explain the different inputs, lifetimes and placements, and why the decision must be re-made per request.
Show where each is enforced in a layered system and how authentication strength and age feed policy.
Argue for one identity model and one enforcement point across services, and for making assurance an explicit policy input rather than a flag.
## Precise definitions **Identification** is the claim: 'I am user 42'. It is unverified input. **Authentication** is producing evidence for that claim and evaluating it - something known, something held, something inherent, or a combination - yielding a principal plus an assurance level and a timestamp. **Authorization** is a decision: given a subject, an action, a resource and surrounding context, permit or deny. **Accounting** records what the principal actually did, and depends on authentication being individual rather than shared. ## Why the separation is structural, not pedantic - **Different inputs.** Authentication consumes credentials and identity-provider state. Authorization consumes domain state: who owns this record, which tenant it belongs to, what its lifecycle status is. A component with credentials but no domain knowledge can do the first and cannot do the second. - **Different lifetimes.** Authentication happens at credential presentation and its result ages. Authorization must be re-decided per request, because the world changes between requests: roles are revoked, ownership transfers, an object moves to a locked state. - **Different placement.** A gateway or proxy is a good place to authenticate and a poor place to authorize anything object-level, because it does not know the resource. Function-level rules ('only administrators may call this operation') can sit at the edge; record-level rules must sit where the record is loaded. - **Different failure modes.** Weak authentication yields impersonation - the attacker becomes someone else. Weak authorization yields escalation - the attacker stays themselves and reaches what is not theirs. Different tests, different logs, different fixes. ## The conflation failure in both directions The common direction is treating a valid session as a permit. Everything after the login page assumes the hard part is done, so handlers read an identifier from the request and act. Because the request carried a valid session, logs look normal and nothing alerts. That is the broken-access-control family that consistently tops industry taxonomies. The reverse direction is subtler: using an authorization artefact as identity. A shared service or integration account passes every policy check while making it impossible to say which human did what, and it usually accumulates the union of everyone's permissions. Similarly, deriving identity from a permission ('anyone who can reach this network is staff') collapses the two concerns and inherits the weakest assumption. ## Where identity strength enters the decision Authentication is not a boolean. It has a strength (which factors, how phishing-resistant), an age (how long since the credential was presented), and a binding (how tightly the credential is tied to a channel or device). Note also that the factor categories matter more than the count: two things the user knows are not two factors. A well-designed policy consumes these: a routine read accepts an old session, while changing a payout destination requires a recent, strong re-authentication. That is only expressible if the two concerns are separate values in the system rather than one flag. Everything downstream is also capped by identity proofing at enrolment and by the account-recovery path - a strong login on an account an attacker recovered is a strong lock on a forged identity. ## The one-line invariant Authentication produces a principal with a confidence level; authorization is a decision made per request from server-owned state about that principal. Neither substitutes for the other, and the presence of the first never implies the second.
- Where in a system should each concern be enforced, and why can a gateway usually not do both?Authentication can be centralised at the edge because it needs only credentials and identity-provider state, and centralising it stops every service reimplementing credential handling. Authorization needs to know the resource - its owner, tenant and state - which the edge generally has not loaded, so anything object-level must be decided where the data is read. A gateway can enforce coarse function-level rules, but treating that as complete authorization is how record-level bugs appear.
- Why does the design need authentication to be more than a boolean flag?Because policies legitimately depend on how the principal authenticated and how recently. A session hours old on an unrecognised device is not equivalent to a fresh strong authentication, and sensitive operations should be able to demand the latter. If the system stores only 'logged in', it cannot express step-up requirements and every operation inherits the weakest login it ever accepted.
saying these in an interview costs you the question
- Defining authorization as 'checking the user is logged in'.
- Assuming a valid session or token implies permission for whatever the request names.
- Using shared service accounts for human actions, which satisfies policy but destroys attribution.
- Deciding authorization once at login and caching the answer for the whole session.