Security
Authentication vs Authorization
Authentication, often shortened to authn, answers 'who is this?' - logging in with a password, a passkey, or a single sign-on provider, so the system has a confirmed identity. Authorization, authz, answers 'what is this identity allowed to do?' - whether that logged-in user can view a specific record, delete a file, or access an admin page. They're often implemented next to each other and easy to conflate, but a system can authenticate someone correctly and still authorize them incorrectly, which is one of the more common and serious classes of access-control bug.
Why it matters
- Confusing the two leads to a specific, common bug class
- Checking 'is this user logged in' where the real question is 'is this user allowed to access this specific record' is how one user ends up able to view or edit another user's data just by changing an ID in a URL.
- Every meaningful action in a system needs both, separately
- Knowing who someone is doesn't say what they're allowed to do, and a system that checks only one of the two has a gap somewhere.
- Session and token handling is where authentication most often breaks in practice
- How a login is remembered between requests needs its own care - expiry, secure storage, invalidation on logout - beyond just checking a password correctly once.
- Authorization needs to be checked on every request, not just at login
- A user's permissions can change, or a request can target a resource the current check never considered, so authorization is re-evaluated per action, not assumed to still hold from login.
Two different questions
A useful way to keep them apart: authentication is a badge that proves who you are, checked once when you arrive; authorization is the door that checks whether your badge lets you into this specific room, checked every time you try one. A protected action in a well-built system always answers both questions - who is asking, and is that specific identity allowed to do this specific thing - not just the first one.
Where authorization checks actually have to live
It's not enough to check that a user is logged in before showing a resource; the check has to confirm that this particular user has rights to this particular resource, every time. Skipping that and relying only on a login check is how one authenticated user ends up able to reach another user's data just by knowing or guessing an identifier, a pattern commonly called an insecure direct object reference.
def get_invoice(request, invoice_id):
invoice = db.find_invoice(invoice_id)
if invoice is None:
return not_found()
if invoice.owner_id != request.user.id:
return forbidden() # authenticated, but not authorized for THIS invoice
return invoiceSessions, tokens, and staying logged in
Once authentication succeeds, something has to represent that login across further requests - typically a session cookie or a bearer token. That representation needs its own protections: an expiry so it doesn't remain valid forever, secure storage and transmission so it can't be trivially intercepted, and a way to invalidate it on logout or a password change, so a stolen token doesn't act as a permanent substitute for the real identity.
Mistakes people make here
- Checking 'is logged in' where the real question is 'is allowed to access this specific resource'
- this is how one authenticated user reads or edits another user's data just by changing an ID in the URL or request body, known as an insecure direct object reference; every access to a specific record needs an ownership or permission check, not just a login check.
- Trusting a role or permission sent from the client
- a role field in a request body, a hidden form field, or a client-side flag can be edited by whoever sends the request; authorization decisions have to be made from data the server already trusts, never from a value the client supplies.
- Never expiring or invalidating sessions and tokens
- a token that's valid forever, with no way to revoke it, means a single leaked token grants access indefinitely; expiry and a revocation path limit how long a leak matters.
- Re-using the same authorization check across very different actions
- being allowed to view a resource doesn't imply being allowed to edit or delete it; each action needs its own check rather than one general 'has access' flag.
- Assuming multi-factor authentication solves authorization problems
- MFA strengthens proving who someone is; it does nothing for a system that, once someone is logged in, fails to check what that specific person should be allowed to touch.
Strengths and trade-offs
Where it is strong
- Separating the two concepts clearly makes access-control bugs much easier to spot in review: 'is logged in' and 'is allowed to do this specific thing' are visibly different checks.
- Modern standards handle a lot of the hard, easy-to-get-wrong parts of authentication, so most applications don't need to build it from scratch.
- Fine-grained, per-resource authorization checks contain the damage of a single account being compromised, rather than exposing everything that account can technically reach.
The trade-offs
- Delegating authentication to a third-party identity provider reduces how much you have to get right yourself, but makes your system dependent on that provider's availability and correctness.
- Fine-grained authorization is more correct but adds real complexity and a performance cost compared to a single coarse 'is logged in' check.
- Session and token expiry is a genuine usability trade-off: shorter expiry is safer and more inconvenient, and there's no setting that's simply better on both axes.
Who needs this
Any developer building or touching a system with user accounts and protected resources - which is most application software. Getting authorization checks right on every endpoint that touches user data is a baseline responsibility, not a specialist concern.
Questions about authentication vs authorization
- What's a simple way to remember the difference?
- Authentication is proving who you are, typically once, at login. Authorization is what that identity is allowed to do, checked again for each specific action. A key card system authenticates you at check-in and authorizes you, per door, every time you badge in - the two checks happen at different times for different reasons.
- What is an insecure direct object reference?
- It's when a system lets a logged-in user access a resource just by knowing or guessing its ID - like an invoice number in a URL - without checking that the resource actually belongs to that user. It's one of the most common real-world access-control bugs, precisely because the authentication check passes and looks fine.
- Should I build my own login system?
- For most applications, no - using a well-established library or an external identity provider avoids a long list of subtle mistakes in password storage, session handling and token validation that have already been solved and hardened by wide use. Custom logic is still needed for authorization, since what a given user can do is specific to the application.
- Does using HTTPS make authentication secure?
- HTTPS protects credentials and tokens in transit between the browser and server, which is necessary but not sufficient - it says nothing about how passwords are stored, how sessions are invalidated, or whether authorization checks are correct once someone is logged in. It's one layer of several.