Authentication vs authorization
Updated 2026-11-13 · 2 min read
Separate identity checks from access decisions, and design tests for roles, ownership and direct API access. Includes a comparison table, concrete examples and an interview answer.
The difference in one table
| Aspect | Authentication | Authorization |
|---|---|---|
| Question | Who is making the request? | May this principal perform this action on this resource? |
| Example | Verify login credentials or a session | Check whether an order belongs to this user |
| Typical failure | Invalid credentials or expired session | Authenticated user lacks required permission |
| Test dimensions | Valid, invalid, expired and revoked credentials | Roles, ownership, tenant boundaries and actions |
| Key caution | Successful login is not unrestricted access | Hiding a button is not server-side enforcement |
Examples
Authentication: in a test environment, Asha signs in using [email protected] and the test account's credentials. Invalid credentials should not establish a session. Expired or revoked credentials should behave according to the session policy.
Authorization: Asha can view her own test order but must not view another account's order merely by changing its identifier. A support role may have different permissions for viewing and refunding. Test these distinctions through the API as well as the UI.
Use separate controlled accounts and fake orders. Confirm that a denial protects both returned data and state changes; an error message alone does not prove nothing happened.
How to answer in an interview
Authentication establishes identity, while authorization decides whether that identity may perform an action on a resource. Logging in as Asha does not entitle her to another customer's order. I test missing or expired credentials separately from roles, ownership and tenant boundaries. I also check direct API requests because a hidden UI action is not an access-control boundary.
Common confusion
Do not reduce authorization to admin versus non-admin: two ordinary users can still have different ownership rights. Also, public resources may intentionally allow anonymous access. Write the expected permissions down before treating every unauthenticated success as a defect.
Likely follow-up: What do 401 and 403 mean here? 401 generally indicates missing or invalid authentication credentials; 403 indicates the server refuses the request, often for permission reasons. Some APIs conceal resource existence with 404.
Quick answers
Does a valid token prove authorization?
No. It can identify a caller while the caller still lacks permission for a particular object, tenant or action.
Should authorization be checked only on login?
No. Enforce the relevant permissions on every protected request. Permissions and resource relationships can change during a session.
Sources
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.