Authentication vs authorisation, MFA and the principle of least privilege

Authentication (AuthN): "Who are you?" It verifies identity: a password, an OTP, a fingerprint, a security key, a certificate.
Authorisation (AuthZ): "What are you allowed to do?" It decides whether an authenticated identity may perform this action on this resource.

Authentication always comes first, but passing it says nothing about permissions. Many serious breaches are authorisation failures: a logged-in user reaches someone else's data by changing an ID in the request. Broken access control is the top category of the OWASP Top 10.

College ERP example

• AuthN: a student logs in with their roll number, a password and an OTP.
• AuthZ: a student may view only their own marks. A faculty member may edit marks only for the courses they teach. The exam cell may publish results. Every request is checked on the server. Hiding a button in the user interface is not access control.
• Models: RBAC (role-based: student, faculty, admin) and ABAC (attribute-based: "faculty.course == marks.course"). Deny by default.

Multi-factor authentication (MFA) needs factors from two or more different categories:

• something you know: a password or PIN;
• something you have: a phone authenticator app (TOTP), a hardware security key, a smart card;
• something you are: a fingerprint or face.

Two passwords are still one factor. MFA blocks most attacks that rely on stolen or guessed passwords. Phishing-resistant methods, FIDO2/WebAuthn security keys and passkeys, are strongest, because they are bound to the real site's domain. SMS OTP is better than nothing but weaker, because of SIM-swap and interception risks.

Principle of least privilege: give every user, service and process only the minimum access it needs, only for as long as it needs it.

• Office staff who print hall tickets do not need database admin rights.
• The web application's database account cannot drop tables.
• Admin rights are granted just in time and expire.
• Access is reviewed and removed when people change roles or leave.

It limits the blast radius: a compromised account or bug can do only limited damage. Related ideas: separation of duties (the person who enters marks is not the one who approves them), defence in depth, and zero trust (verify every request; never trust a request just because it comes from inside the network).