Authentication vs authorization: who you are, and what you may do

Every time you use an app, a website or a company network, two separate questions are answered behind the scenes. First: who is this? Second: what is this person allowed to do? The first question is authentication. The second is authorization. They are often mentioned together, sometimes shortened to “auth”, but they are different jobs, done at different moments, and they fail in different ways.

Authentication: proving an identity

Authentication is the act of proving that you are the person, device or program you claim to be. NIST’s digital identity guidelines (SP 800-63B) describe it in terms of “authenticators”: something you know, like a password; something you have, like a phone or a security key; and something you are, like a fingerprint. A login screen, a Touch ID prompt and a code sent to your phone are all authentication steps.

Authentication answers a yes-or-no question about identity, and nothing else. Knowing that the person at the keyboard really is Sarah from accounting does not, by itself, say whether Sarah may read the payroll file.

Authorization: deciding what is allowed

Authorization happens after authentication. The system takes the proven identity and checks it against rules: which files, which functions, which records this identity may read, change or delete. A shared folder that only the finance team can open, a “delete” button that only administrators see, a banking app that lets you view your own account but not your neighbour’s: all of these are authorization decisions.

Why the difference matters: two kinds of failure

When authentication fails, an attacker gets in as someone else: a stolen password, a phished login, a reused credential from another breach. MITRE ATT&CK lists the use of stolen accounts as a technique of its own (T1078, “Valid Accounts”), because once an attacker holds real credentials, their activity can look like normal use.

When authorization fails, a legitimate user reaches things they should never see. OWASP ranks “Broken Access Control” first in its Top 10 of web application risks (2021): users changing an ID in a web address to read someone else’s invoice, regular accounts reaching admin pages, or an app that checks permissions in the interface but not on the server. The person is who they say they are; the system simply trusts them too much.

How to implement authentication well

• Prefer phishing-resistant methods: passkeys and hardware security keys resist fake login pages because they are tied to the real website. The next lesson on identity verification goes deeper.
• Add a second factor wherever a password is still used. CISA calls multifactor authentication one of the most effective steps an organisation can take.
• Follow NIST’s password guidance: favour length over forced complexity, check new passwords against lists of known-breached ones, and stop forcing routine password changes when there is no sign of compromise.
• Protect the recovery path. Password reset and account recovery are authentication too, and attackers often target them because they are weaker than the login itself.
• Limit guessing: rate-limit login attempts and alert on unusual sign-in patterns.

How to implement authorization well

• Deny by default. OWASP’s authorization guidance recommends that access is refused unless a rule explicitly allows it.
• Check on the server, every time. Hiding a button in the interface is not a control; the server must verify the permission for each request.
• Apply least privilege: give each person and each program only the access its job needs, for as long as it needs it.
• Centralise the rules so they are consistent and auditable, rather than scattered across the code.
• Log authorization failures. A burst of “access denied” events is often the first sign that someone is probing.

Programs need authentication and authorization too

People are not the only identities. Apps, scripts and background services also act on your behalf, and they also need to be identified and limited. On a Mac, apps are identified by their code signature, which proves who made them and that they have not been altered. FireAI uses that signature to decide which app is asking to connect, and its per-app rules are authorization in practice: a given app may reach these destinations and not others. Because rules follow the signature rather than the app’s name, an impostor that copies a trusted app’s name does not inherit its permissions.

If you want to see how these two ideas fit into a wider strategy, the “Layers of security” course shows where identity sits among the other defences, and the zero trust lesson at the end of this course shows what happens when every request, not just the first login, has to pass both checks.