Authentication vs Authorisation

Leo logs into the shop's cloud drive, then tries to open the Payroll folder and gets "Access denied". His password was right. So what went wrong? Nothing: two different checks happened, and he passed only the first. Mixing up those two checks is behind many real security mistakes.

The rule

Authentication asks who you are; authorisation asks what you may do.

• Authentication (often shortened to authn) proves identity. It is based on one or more factors:
  • something you know — a password or PIN,
  • something you have — a phone, a security key, a card,
  • something you are — a fingerprint or face.
• Authorisation (authz) happens after identity is known. It checks permissions: may this person read, change or delete this thing? This is where least privilege lives.

Authentication always comes first; you cannot decide what someone may do until you know who they are. But passing authentication must never mean "allowed to do everything".

Both checks depend on one person, one account. If three staff share a login called shop, authentication can only prove "someone who knows the shop password", authorisation cannot be tailored to each job, and the logs cannot say who did what.

A useful everyday picture is a hotel. Showing your passport at the desk is authentication. The key card that opens only room 214 is authorisation.

The shortcut

When access fails or a design is being checked, ask "Is this about proving the person, or about their permissions?" Proof of identity: authentication. Permission: authorisation.

The trap in building systems is checking only authentication, for example a web page that any logged-in user can open just by guessing its address. Every sensitive action needs its own authorisation check.

Drills

Answer fast — trust the rule.

Remember

• Authentication asks who you are; authorisation asks what you may do.
• Ask: is this about proving the person, or about their permissions?
• Trap: treating "logged in" as "allowed", and sharing accounts.