Inquiry Question 1: How are secure systems designed?
Explain the role of authentication and authorisation in restricting access to a system, and identify common implementation methods including multi-factor authentication and role-based access control
A focused answer to the HSC Software Engineering Module 1 dot point on authentication and authorisation. The difference between the two, multi-factor authentication, role-based access control, the worked SaaS-app example, and the traps markers look for.
Reviewed by: AI editorial process; not yet individually human-reviewed
Have a quick question? Jump to the Q&A page
What this dot point is asking
NESA wants you to clearly distinguish authentication (who you are) from authorisation (what you can do), and describe the standard implementations of each: passwords, multi-factor authentication, single sign-on, role-based access control, and the principle of least privilege.
The answer
Authentication: proving who you are
Authentication confirms a user's identity. It relies on one or more factors:
- Something you know: a password or PIN.
- Something you have: a phone (for SMS or authenticator app codes), a hardware security key (YubiKey), or a smart card.
- Something you are: a biometric like a fingerprint or face scan.
Single-factor authentication (just a password) is weak. Multi-factor authentication (MFA) combines two or more factor categories, dramatically reducing the success rate of credential-theft attacks.
Authorisation: deciding what you can do
Once a user is authenticated, authorisation governs which actions they can perform and which resources they can access. The two dominant models:
- Role-based access control (RBAC). Users are assigned roles; roles have permission sets. Easy to administer at scale. Used in most SaaS apps.
- Attribute-based access control (ABAC). Permissions are computed from user attributes, resource attributes, and environmental context (time of day, IP address). More flexible, more complex.
Least privilege
Whichever model is used, the principle of least privilege says give each user only the permissions strictly needed for their role. A junior support agent does not need access to billing data. A read-only auditor never needs write permissions.
An owned schematic shows the full request pipeline: authentication establishes identity once, then authorisation is re-checked on every subsequent request against that identity's role.
Sessions and tokens
Once a user authenticates, the system must remember them across requests without re-checking their password each time. This is done with a session: the server creates a session record and gives the browser a session identifier stored in a cookie, marked HttpOnly and Secure so scripts cannot read it and it travels only over HTTPS. Token-based schemes such as JSON Web Tokens (JWTs) instead hand the client a signed token carrying its identity and roles, which the server verifies on each request without a lookup. Both approaches must expire credentials, support logout (invalidating the session or token), and protect against theft, because a stolen session token lets an attacker impersonate the user without ever knowing the password. Treating session management as part of authentication is exactly the kind of design detail markers reward.
Single sign-on and federated identity
Large systems often delegate authentication to a trusted identity provider through single sign-on (SSO) using protocols like OAuth 2.0 and OpenID Connect. The user authenticates once with the provider (for example, a Google or school identity account) and other applications trust the provider's assertion of identity. This improves usability (one strong credential), centralises MFA enforcement, and removes the need for every app to store passwords, but it also concentrates risk: if the identity provider is breached, every connected application is exposed. The engineering trade-off is convenience and central control versus a single high-value target.
Implementation in Python (Flask)
from flask import Flask, request, abort
from functools import wraps
ROLES = {
"alice": "admin",
"bob": "auditor",
"carol": "support",
}
PERMISSIONS = {
"admin": {"view", "edit", "delete"},
"auditor": {"view"},
"support": {"view", "edit"},
}
def authenticate(username, password):
# ... verify credentials against hashed password store ...
return ROLES.get(username)
def require_permission(perm):
def decorator(f):
@wraps(f)
def wrapper(*args, **kwargs):
role = request.headers.get("X-Role")
if perm not in PERMISSIONS.get(role, set()):
abort(403)
return f(*args, **kwargs)
return wrapper
return decorator
@app.route("/users/<id>", methods=["DELETE"])
@require_permission("delete")
def delete_user(id):
# ... delete logic ...
return "", 204
The authenticate function checks identity. The require_permission decorator checks authorisation. Separating the two is the standard pattern.
Exam-style practice questions
Practice questions written in the style of NESA exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.
2024 HSC5 marksDistinguish between authentication and authorisation, and describe how a system administrator could combine multi-factor authentication and role-based access control to secure an admin portal.Show worked answer →
Authentication is verifying who a user is. Authorisation is deciding what an authenticated user is allowed to do. Authentication happens first; authorisation depends on the identity it produces.
A typical admin portal combines both with two extra layers.
Multi-factor authentication (MFA). When the admin signs in, they supply something they know (a password) and something they have (a one-time code from an authenticator app or hardware key). Even if the password leaks, the attacker still needs the second factor. MFA reduces the risk of credential-theft attacks (phishing, brute force) to near zero.
Role-based access control (RBAC). After authentication, the system assigns the user a role (for example, super-admin, read-only-auditor, support-agent). Each role has a permission set. The super-admin can edit billing settings; the auditor can only view audit logs; the support agent can reset user passwords but not view payment cards.
Together, MFA stops attackers reaching the portal, and RBAC limits the damage if a low-privilege account is compromised. Markers reward the clear distinction between authentication and authorisation, named MFA factors, and a concrete RBAC example.
HSC 20223 marksDefine the principle of least privilege and explain, with an example, how it reduces the impact of a compromised account.Show worked answer →
The principle of least privilege states that each user, process or service should be granted only the minimum permissions needed to perform its function, and nothing more. For example, a customer-support agent is given a role that can reset passwords and view ticket data but cannot access payment-card records or change billing. If that agent's account is phished, the attacker inherits only those limited permissions, so they cannot exfiltrate card data or alter billing; the blast radius of the breach is contained. Markers reward the correct definition, a concrete restricted-role example, and the link between limited permissions and reduced breach impact.
HSC 20244 marksEvaluate the use of multi-factor authentication for a public web application, considering both security benefits and usability costs.Show worked answer →
MFA combines two or more factor categories (knowledge, possession, inherence), so even if a password is stolen through phishing or a breach, the attacker still needs the second factor, which dramatically lowers the success rate of credential-theft attacks. The usability costs are real: extra steps at sign-in, the risk of users being locked out if they lose a device, support overhead for recovery, and potential exclusion of users without smartphones. A balanced evaluation concludes MFA is justified for accounts holding sensitive data or money, ideally offering several second-factor options (authenticator app, hardware key, backup codes) and risk-based prompts to limit friction. Markers reward a clear security benefit, a genuine usability cost, and a reasoned judgement rather than a one-sided answer.
Practice questions
Original practice questions graded from foundation to exam level, each with a full worked solution. Try them before revealing the solution.
foundation3 marksDistinguish between authentication and authorisation, giving one concrete example of each in the context of a school's online portal.Show worked solution →
Authentication verifies identity: a student logs in with their school email and password, and the school's identity server confirms the credentials match its records.
Authorisation decides access: once logged in, the portal checks the student's role and allows them to view only their own timetable and grades, not another student's.
Marking criteria: 1 mark for a correct definition of authentication, 1 mark for a correct definition of authorisation, 1 mark for a concrete portal example that clearly separates the two steps.
foundation4 marksThe table below lists four authentication checks used by a banking app. Classify each as "something you know", "something you have" or "something you are", then state which factor category is missing from the set. (i) 4-digit PIN entered on login. (ii) Six-digit code generated by an authenticator app on the customer's phone. (iii) Fingerprint scan on the banking app. (iv) Security question answer (mother's maiden name).Show worked solution →
(i) PIN: something you know.
(ii) Authenticator app code: something you have (possession of the registered phone).
(iii) Fingerprint scan: something you are (biometric/inherence).
(iv) Security question: something you know (a memorised fact, the same category as the PIN).
All three factor categories appear across the four checks, but items (i) and (iv) both fall in "something you know", so combining only those two would still be single-factor in practice; a true MFA design should pair a "know" item with the "have" or "are" item.
Marking criteria: 1 mark per correct classification (up to 4 items, capped at 3 marks for classification), 1 mark for correctly identifying that (i) and (iv) are the same category and explaining why pairing them would not count as genuine MFA.
core5 marksA university enrolment system has four roles: student, tutor, unit-coordinator and admin. Design an RBAC permission table for these roles across the actions view-own-grades, view-cohort-grades, edit-grades and manage-enrolments, then justify one restriction using the principle of least privilege.Show worked solution →
| Role | view-own-grades | view-cohort-grades | edit-grades | manage-enrolments |
|---|---|---|---|---|
| Student | yes | no | no | no |
| Tutor | yes | yes (own class) | no | no |
| Unit-coordinator | yes | yes | yes | no |
| Admin | no (not enrolled) | yes | no | yes |
Justification (least privilege). The tutor can view their class's grades to give feedback but cannot edit them, because grade entry is reserved for the unit-coordinator; this means a compromised tutor account cannot alter a student's final result, containing the impact of any single breach.
Marking criteria: 1 mark for a complete and internally consistent table, 1 mark for each of two clearly differentiated roles beyond student (up to 2 marks), 1 mark for a least-privilege justification that names a specific restricted action and explains the reduced blast radius.
core4 marksExplain the difference between a stolen password and a stolen session token, and why session tokens must still be protected even when passwords are hashed correctly.Show worked solution →
A stolen password lets an attacker authenticate as the user directly, by presenting the credential at the login form; if MFA is enabled, the attacker is stopped at the second factor.
A stolen session token (or JWT) bypasses login entirely: the server has already authenticated the holder of that token once, so a script or man-in-the-middle that captures it can impersonate the user for the token's lifetime without knowing the password or completing MFA at all.
Hashing protects the password at rest in the database, but it does nothing to protect a live session token in transit or in browser storage; that requires separate controls such as HttpOnly and Secure cookie flags, short token lifetimes, and HTTPS everywhere.
Marking criteria: 1 mark for explaining password theft requires re-authentication (and can be stopped by MFA), 1 mark for explaining session-token theft bypasses login/MFA, 1 mark for noting hashing does not protect live tokens, 1 mark for naming a concrete session-protection control.
core4 marksA start-up wants to let staff log into its internal tools using their existing Google account instead of creating a new password for each tool. Explain how single sign-on achieves this, and identify one new risk it introduces.Show worked solution →
With single sign-on, the staff member authenticates once with the identity provider (Google), which issues a signed assertion of identity, typically via OpenID Connect built on OAuth 2.0. Each internal tool trusts that assertion instead of maintaining its own password database, so the user is redirected to Google to sign in, then returned to the tool already authenticated.
This removes duplicate passwords and lets the start-up enforce MFA in one place (on the Google account) rather than in every tool separately.
New risk. The identity provider becomes a single point of failure: if the staff member's Google account is compromised, or Google's service has an outage, every connected internal tool is simultaneously exposed or unavailable, whereas previously a breach of one tool's password would not affect the others.
Marking criteria: 1 mark for correctly describing the SSO authentication flow, 1 mark for naming a relevant protocol (OAuth 2.0 or OpenID Connect), 1 mark for identifying the single-point-of-failure risk, 1 mark for explaining its consequence (breach or outage affects all connected tools).
exam8 marksDesign a complete authentication and authorisation architecture for a new telehealth application used by patients, doctors and clinic administrators. Your answer must address factor choice and MFA, an authorisation model with at least three roles, session or token management, and one deliberate trade-off you accepted and why.Show worked solution →
This is an extended-response design question: markers reward a coherent, justified architecture, not just a list of buzzwords.
- Authentication
- Use MFA for every account: a password (something you know) plus a time-based one-time code from an authenticator app (something you have). Doctors and administrators, who can view many patients' records, require MFA on every login; patients are prompted for MFA at login and again before viewing sensitive test results, a risk-based step-up approach.
- Authorisation (RBAC)
- Three roles: patient (view own records, message their own doctor, book appointments), doctor (view and edit records for their own patients only, prescribe), clinic-admin (manage appointments and billing, but cannot view clinical notes). This enforces least privilege: a compromised admin account cannot leak medical history, and a compromised patient account cannot reach any other patient's data.
- Session/token management
- Use short-lived JWTs (fifteen minutes) with a longer-lived refresh token stored in an HttpOnly, Secure cookie, so a stolen access token has a small window of use, and logout revokes the refresh token immediately.
- Trade-off accepted
- Requiring MFA on every doctor login adds friction during busy clinic hours; the design accepts this usability cost because doctors' accounts have wide read access across many patients' confidential records, so the CIA-triad benefit to confidentiality outweighs the extra ten seconds per login.
Marking criteria: 2 marks for a justified MFA design naming factor categories, 2 marks for a three-plus role RBAC model with least privilege reasoning, 2 marks for concrete session/token handling, 2 marks for an explicit trade-off with a reasoned justification.
exam6 marksEvaluate whether a small business should adopt single sign-on through a third-party identity provider or continue managing its own per-application passwords, considering security, usability and cost.Show worked solution →
A strong evaluation weighs both options against all three criteria and reaches a justified recommendation.
- Security
- SSO centralises MFA enforcement and removes weak, reused passwords across separate apps, but concentrates risk: a breach of the identity provider or the owner's own SSO account exposes every connected system at once. Per-application passwords isolate breaches to one system but are far more likely to be weak or reused in practice, since staff manage many separate credentials.
- Usability
- SSO is clearly better for staff, one strong login instead of many, and reduces password-reset support tickets. Per-application logins create password fatigue, which often leads to insecure workarounds like reused or written-down passwords.
- Cost
- SSO via a provider (for example, Google Workspace or Microsoft Entra) typically has a per-seat subscription cost but removes the ongoing cost of building and patching separate login systems; self-managed passwords avoid a subscription but carry hidden costs in support time and breach risk from weaker practice.
- Judgement
- For a small business without a dedicated security team, SSO through an established provider is the stronger choice: it improves both security (centralised MFA, no weak app-specific passwords) and usability at a predictable cost, and the single-point-of-failure risk is smaller than the aggregate risk of several separately weak password stores, provided the SSO account itself is protected with strong MFA.
Marking criteria: 2 marks for balanced security discussion (both directions), 1 mark for usability, 1 mark for cost, 2 marks for an explicit, reasoned judgement rather than a neutral summary.