Lesson 2.6: Authentication and Authorization

00 Introduction

Identity and access management, examined in Lesson 2.5, provides the infrastructure. Authentication and authorization are the decisions that infrastructure exists to make.

Authentication establishes that a subject is who they claim to be. Authorization determines what that subject is permitted to do. The two are distinct — a common source of conceptual and implementation error — and both must be correct for access control to be effective.

This lesson examines both decisions in detail. On the authentication side, it covers the factors of authentication, the mechanisms that implement them (passwords, hardware tokens, biometrics, federated assertions), multi-factor authentication, and session management — the often-overlooked discipline that determines how authentication persists over time. On the authorization side, it covers the principal access-control models — discretionary, mandatory, role-based, attribute-based, and relationship-based — and the criteria for selecting among them.

The material here draws on Lessons 2.1–2.5. Authentication mechanisms depend on cryptography (Lessons 2.1–2.4) and on identity infrastructure (Lesson 2.5). Authorization decisions depend on the attributes and entitlements managed through IAM. The lesson also prepares for Lesson 2.7, which develops Zero Trust — the paradigm that places authentication and authorization at the centre of every access decision, regardless of network location.

How to read this lesson

Sections 1–5 address authentication. Sections 6–8 address authorization. Section 9 examines enterprise practice and failures. If you are short on time, read Sections 4, 7, and 9 carefully — multi-factor authentication, the RBAC-versus-ABAC comparison, and enterprise failure modes are the most consequential material for assessment and for practice.

01 Learning objectives

By the end of this lesson you should be able to:

Lesson objectives

Distinguish authentication from authorization and explain why the distinction matters.
Describe the factors of authentication and the mechanisms that implement each.
Explain multi-factor authentication, its benefits, and the mechanisms through which it can be bypassed.
Explain single sign-on and session management, and the security considerations they introduce.
Compare the principal authorization models — DAC, MAC, RBAC, ABAC, ReBAC.
Select authentication mechanisms and authorization models appropriate to an enterprise context.
Analyse common authentication and authorization failures and the lessons they carry.

These objectives contribute to Unit 2 outcomes U2.2 (authentication technologies) and U2.3 (access-control design), and to Module 1 outcome M1.13 (access-control and authentication models). See the Unit 2 learning outcomes page for the full mapping.

02 Authentication versus authorization

Authentication and authorization are frequently conflated. They are distinct operations, performed at different points in the access decision, and governed by different mechanisms.

Authentication and authorization compared
Dimension	Authentication	Authorization
Question answered	Who is this subject?	What is this subject permitted to do?
Timing	Occurs at the beginning of a session (and periodically thereafter)	Occurs for every access decision, including within a session
Frequency	Once per session, subject to re-authentication	Continuously, for every resource access
Mechanisms	Passwords, tokens, biometrics, certificates, federated assertions	Access-control models — DAC, MAC, RBAC, ABAC, ReBAC
Failure mode	Impersonation — an attacker is mistaken for a legitimate subject	Privilege escalation — a subject gains access beyond their authority
Data required	Credentials, identity assertions	Identity attributes, entitlements, policies, context
Typical weakness	Weak credentials, credential theft, MFA bypass	Over-permissive policies, privilege creep, missing enforcement

Why the distinction matters

The distinction matters for three reasons:

They have different failure modes. A system with strong authentication and weak authorization can correctly identify a subject and then allow them to do things they should not be permitted to do. A system with strong authorization and weak authentication can correctly restrict what a subject is permitted to do, while being unable to establish which subject is making the request.
They require different controls. Improving authentication involves strengthening credentials and mechanisms; improving authorization involves defining and enforcing access policies. Investment in one does not automatically improve the other.
They are often conflated in practice. Many enterprise security programmes discuss "access control" as though it were a single capability. Making the distinction explicit improves analysis and investment decisions.

Both decisions are necessary for effective access control. Authentication establishes the subject; authorization determines what they may do. The enterprise needs both, and the design of one should not obscure the needs of the other.

A useful test

When examining an access-control failure, ask: was the failure of authentication or of authorization? If an attacker logged in with stolen credentials and then accessed data they were entitled to, the failure was of authentication. If a legitimate user accessed data beyond their authority, the failure was of authorization. The distinction determines where remediation effort should be directed.

03 Authentication factors

Authentication relies on factors — categories of evidence that a subject can present to establish their identity. The classical model recognises three factors, extended in some frameworks to include a fourth.

Something you know

Knowledge-based factors: passwords, passphrases, PINs, answers to security questions. Vulnerable to guessing, phishing, credential stuffing, and reuse across services.

Something you have

Possession-based factors: hardware tokens, smart cards, mobile devices, authenticator apps, FIDO2 security keys. Resistant to remote guessing but vulnerable to theft, loss, and physical access.

Something you are

Inherence-based factors: fingerprints, facial recognition, iris scans, voice patterns, behavioural biometrics. Difficult to steal remotely but raise privacy concerns and are not revocable if compromised.

Something you do

Behavioural factors: typing patterns, gait, mouse movement, usage patterns. Used in continuous authentication and anomaly detection rather than as a primary factor.

Factor strength

The factors are not equivalent. Their relative strength depends on the threat model and on the deployment context, but some general observations hold:

Knowledge factors are the weakest. They can be guessed, phished, observed, reused, and shared. They are also the most widely deployed because they require no additional hardware.
Possession factors are stronger against remote attack but vulnerable to physical theft and to phishing of one-time codes. Their strength depends substantially on the specific mechanism.
Inherence factors are strong against remote attack but raise privacy and consent issues, and cannot be changed if compromised. Their use requires careful consideration of regulatory and ethical constraints.
Behavioural factors are complementary. They are rarely used as sole authentication but are valuable for continuous verification — detecting that a session's behaviour has changed in ways consistent with compromise.

Combining factors: multi-factor authentication

Multi-factor authentication (MFA) requires evidence from two or more distinct factors. The key word is distinct — requiring a password and a security question is not MFA, because both are knowledge factors. Requiring a password and a code from an authenticator app is MFA, because the password is knowledge and the code is possession.

MFA substantially improves resistance to credential-based attacks. Passwords alone can be phished, guessed, or reused across services; a second factor from a different category raises the barrier considerably. MFA is examined further in Section 4.

The most common misconception

Requiring two different credentials is not necessarily MFA. Two passwords, a password and a PIN, or a password and a security question are all single-factor (knowledge) authentication with additional steps. MFA requires evidence from distinct factors, and the security benefit derives from the distinctness.

04 Authentication mechanisms

Each factor is implemented through specific mechanisms. Understanding the mechanisms — their strengths, their failure modes, and their appropriate uses — is essential to designing enterprise authentication.

Password-based authentication

Passwords remain the most widely deployed authentication mechanism despite their well-known weaknesses. Their persistence reflects their practicality: they require no additional hardware, they are well understood by users, and they are supported by every system. Their weaknesses are equally well understood.

Reuse. Users reuse passwords across services, so a breach at one service compromises accounts at others. Credential stuffing — using credentials from one breach to attack other services — is a common attack.
Weakness. Users choose predictable passwords, particularly when password complexity requirements encourage predictable patterns (Password1!, SeasonYear!).
Phishing. Passwords can be captured through phishing attacks, sometimes at scale.
Credential theft. Passwords can be extracted through malware, keyloggers, or breach of a system that stores them.
Storage weaknesses. Systems that store passwords improperly — with weak hashing, without salt, or with reversible encryption — expose them when breached.

The countermeasures are well established: strong password hashing (bcrypt, scrypt, Argon2) with salt and adequate iteration; password length minimums rather than complexity requirements; breached-password checking; rate limiting and account lockout; and, above all, the addition of a second factor. Modern guidance increasingly deprecates periodic forced rotation, which encourages weaker passwords, in favour of continuous monitoring for compromise.

One-time passwords and authenticator apps

One-time passwords (OTPs) are single-use codes that expire quickly — typically within a minute. They are commonly used as a second factor, delivered either through a hardware token, an authenticator app, or a text message.

Hardware OTP tokens. Dedicated devices that generate codes. Strong against remote attack; vulnerable to physical theft and to real-time phishing where the attacker obtains the code before it expires.
Authenticator apps (TOTP). Applications that generate codes based on a shared secret and the current time. More secure than SMS, more convenient than hardware tokens; still vulnerable to real-time phishing and to malware that extracts the shared secret.
SMS-delivered codes. Codes delivered by text message. The weakest OTP mechanism — vulnerable to SIM swapping, network interception, and social engineering of mobile carriers. Modern guidance discourages SMS for high-value accounts.
Push notifications. Codes or approvals delivered through a mobile app. Convenient but vulnerable to MFA fatigue attacks — repeatedly sending push notifications until the user approves one to stop the annoyance.

FIDO2 and WebAuthn

FIDO2 and its underlying standard WebAuthn represent a fundamentally different approach to authentication. Instead of codes that can be phished, FIDO2 uses public-key cryptography bound to a specific origin (website or service). The authenticator — a hardware security key, a platform authenticator (Touch ID, Windows Hello), or a mobile device — holds a private key and signs a challenge issued by the service.

The result is phishing-resistant authentication. Because the signature is bound to a specific origin, a phishing site cannot obtain a valid signature even if it captures the interaction. The private key never leaves the authenticator, so there is no credential to steal. FIDO2 is widely regarded as the strongest available authentication mechanism for general use, and modern guidance increasingly recommends it for high-value accounts and for administrators.

Certificate-based authentication

Certificate-based authentication uses X.509 certificates (Lesson 2.4) to authenticate subjects. The subject proves possession of the private key corresponding to the certificate, typically through a cryptographic challenge-response protocol. This mechanism is used in mutual TLS, smart card authentication, and device authentication.

Certificate-based authentication is strong: the private key is protected (typically in a hardware token or TPM), and the cryptographic challenge cannot be replayed or phished in the way a password can. Its challenges are operational — certificate lifecycle management, revocation, and the infrastructure required to issue and manage certificates.

Biometric authentication

Biometric authentication uses physical or behavioural characteristics of the subject. Common biometrics include fingerprints, facial recognition, iris scans, and voice patterns.

Biometrics are powerful for local authentication — unlocking a device, accessing a physical facility — but present challenges in enterprise deployments:

Irrevocability. If a biometric is compromised, it cannot be changed. A password can be reset; a fingerprint cannot.
Privacy and consent. Biometric data is sensitive personal data subject to privacy regulation in many jurisdictions.
False acceptance and false rejection. Biometric systems balance the risk of accepting an impostor against the inconvenience of rejecting a legitimate user. Neither error rate is zero.
Presentation attacks. Biometric systems can be defeated through presentation attacks — photographs, masks, recorded audio — unless liveness detection is implemented.
Storage. Biometric templates must be stored securely, and their compromise is consequential because the underlying characteristic cannot be replaced.

In enterprise practice, biometrics are frequently used as a local authenticator (unlocking a device or hardware token) rather than as a remote authentication factor, with the cryptographic strength of FIDO2 or certificate-based authentication providing the security guarantee.

The modern hierarchy

Where the enterprise can choose, a reasonable ordering of strength is: FIDO2/WebAuthn (phishing-resistant) — strongest; certificate-based authentication (strong, requires infrastructure); hardware OTP tokens and authenticator apps (strong but vulnerable to real-time phishing); push notifications (convenient, vulnerable to fatigue attacks); SMS OTP (weak, discouraged for high-value accounts); passwords alone (weakest, acceptable only when combined with a strong second factor).

05 Multi-factor authentication

Multi-factor authentication is the practice of requiring evidence from two or more distinct authentication factors. It is one of the most effective controls available against credential-based attacks, and modern enterprise practice increasingly treats it as a baseline rather than as an optional enhancement.

What MFA provides

MFA substantially reduces the risk from credential theft. An attacker who obtains a password — through phishing, breach, or reuse — cannot authenticate without also obtaining the second factor. This raises the cost of attack considerably and reduces the effectiveness of common attacks such as credential stuffing and password spraying.

MFA also reduces the impact of password reuse. A password compromised at another service cannot be used to authenticate to an MFA-protected system. This is particularly valuable in enterprise environments where user behaviour cannot be fully controlled.

How MFA is bypassed

MFA is not a complete defence. Attackers have developed techniques to circumvent it, and understanding these techniques is essential to deploying MFA effectively.

MFA bypass techniques and countermeasures
Technique	How it works	Countermeasure
Real-time phishing	A phishing site proxies the legitimate site, capturing both password and OTP as the user enters them, and using them to authenticate in real time.	Phishing-resistant MFA (FIDO2); user education; URL verification; email security.
MFA fatigue / prompt bombing	The attacker repeatedly triggers MFA prompts until the user approves one to make the prompts stop.	Number matching; rate limiting of prompts; user education; anomaly detection.
SIM swapping	The attacker social-engineers the mobile carrier into transferring the victim's number to a SIM the attacker controls, then receives SMS OTPs.	Avoid SMS OTP for high-value accounts; carrier account hardening; alternative factors.
Session hijacking	The attacker captures the session token after MFA has been completed, allowing them to use the authenticated session without re-authenticating.	Short session lifetimes; binding sessions to device characteristics; session monitoring; secure cookies.
Adversary-in-the-middle (AiTM) phishing	Sophisticated phishing frameworks that proxy the entire session, capturing the session token after MFA.	Phishing-resistant MFA; token binding; detection of unusual session patterns.
Malware on the device	The attacker installs malware that intercepts credentials and MFA codes, or that manipulates the browser session.	Endpoint protection; device attestation; strong endpoint posture.
Helpdesk social engineering	The attacker contacts the helpdesk, impersonates the user, and persuades the helpdesk to reset MFA or bypass it.	Strong helpdesk identity verification; restrictions on MFA reset; logging of resets.

Selecting MFA mechanisms

The choice of MFA mechanism matters as much as the decision to deploy it. Useful guidance:

For administrators and privileged users: phishing-resistant MFA (FIDO2) is strongly recommended. The concentration of risk in these accounts justifies the strongest available mechanism.
For general users: authenticator apps (TOTP) or push notifications with number matching provide substantial improvement over passwords alone. FIDO2 is preferred where feasible.
Avoid SMS where alternatives exist. SMS is better than no second factor, but it is vulnerable to SIM swapping and interception. Modern guidance discourages SMS for high-value accounts.
Deploy phishing-resistant MFA where the threat justifies it. For high-value users, for access to sensitive systems, and where the enterprise's threat model includes sophisticated adversaries, FIDO2 or certificate-based authentication should be preferred.
Provide fallback mechanisms. Users lose devices, forget passwords, and need recovery paths. Fallback mechanisms must be secure — they are a common bypass route for MFA.

The most common deployment mistake

The most common MFA deployment mistake is not the choice of mechanism but the handling of exceptions and fallbacks. Organisations that deploy strong MFA and then provide a trivially exploitable fallback — password reset through email, helpdesk bypass, or shared recovery codes — undermine the security the MFA was intended to provide. Fallbacks must be at least as strong as the primary mechanism.

06 Single sign-on and session management

Authentication does not end when a subject first proves their identity. Sessions persist, tokens are issued, and the security of the session determines whether the authentication remains meaningful over time. Session management is often overlooked in enterprise security discussions, but it is where authentication failures increasingly occur.

Single sign-on

Single sign-on (SSO), introduced in Lesson 2.5 as a benefit of federation, enables a subject to authenticate once and access multiple applications without re-authenticating. It is one of the most significant practical improvements in enterprise authentication, both for usability and for security.

SSO improves security in several respects:

Centralised authentication. Authentication happens in one place, against one set of policies. Strong authentication mechanisms can be applied consistently across all applications.
Reduced password reuse. Users authenticate to the SSO provider rather than maintaining separate credentials for each application, reducing password reuse and the associated risk.
Simplified de-provisioning. Disabling a subject in the identity provider revokes access to every federated application, without requiring per-application de-provisioning.
Centralised audit. Authentication events are logged in one place, supporting investigation and monitoring.

SSO also concentrates risk. Compromise of an SSO credential provides access to every application the SSO covers, which makes protection of the SSO credential more important than protection of any individual application credential. Strong authentication — particularly phishing-resistant MFA — and robust session management are essential for SSO deployments.

Session management

A session is the period during which a subject's authenticated state persists. Sessions are typically maintained through session tokens — cookies, bearer tokens, or equivalent — issued at authentication and presented with subsequent requests.

Session management determines how long a subject remains authenticated, how the session is protected, and what happens when the session is compromised. Poor session management is a common and consequential source of authentication failure.

Session management considerations
Consideration	Description
Session lifetime	How long a session remains valid. Shorter lifetimes reduce exposure if a token is compromised; longer lifetimes improve usability. Absolute and idle timeouts are commonly combined.
Token storage	How the session token is stored — secure cookies, in-memory storage, local storage. Storage choices affect vulnerability to cross-site scripting and token theft.
Token scope	What the token authorises. Narrowly scoped tokens reduce the impact of compromise; broadly scoped tokens enable single-token access to many resources.
Re-authentication	Whether and when the subject must re-authenticate during a session. Step-up authentication for sensitive operations is increasingly common.
Session invalidation	How sessions are terminated — on logout, on password change, on administrative action, on suspicious activity. Server-side invalidation is not always implemented; clients may hold tokens that the server cannot revoke.
Session binding	Whether the session is bound to a specific device, IP, or other characteristic. Binding can detect token theft but can be bypassed and can cause usability issues.
Concurrent sessions	Whether a subject can hold multiple simultaneous sessions, and how they are managed. Limits on concurrent sessions reduce exposure but complicate legitimate multi-device use.
Cross-site scripting protection	Whether tokens are protected from cross-site scripting, which can steal session tokens and allow the attacker to hijack the session.

Token-based authentication

Modern applications frequently use token-based authentication, in which the subject presents a token (rather than re-authenticating on every request). Common token formats include JSON Web Tokens (JWTs), opaque tokens verified by the issuer, and SAML assertions.

Tokens introduce their own security considerations:

Token validation. The token must be validated cryptographically — signature, expiry, issuer — on every use. Applications that accept tokens without validation expose themselves to token forgery.
Token revocation. JWTs are often stateless and cannot be revoked individually before expiry. This creates a window during which a compromised token remains valid. Short token lifetimes or token revocation lists mitigate the risk.
Token binding. Some deployments bind tokens to specific clients, reducing the value of stolen tokens. Support is not universal.
Scope and audience. Tokens should be scoped to the resources they authorise and to the audience for which they are intended. Broadly scoped tokens are a common weakness.
Token leakage. Tokens stored in logs, in URLs, or in insecure storage can be captured. Careful handling is essential.

The most consequential session failure

The most consequential session failure is the inability to invalidate sessions. If a subject's session cannot be terminated — after a password change, after a suspected compromise, after de-provisioning — the attacker who has captured the session token retains access for as long as the token remains valid. Enterprises that deploy strong authentication and weak session management have strengthened the front door while leaving the back door open.

07 Authorization models

Authorization determines what an authenticated subject is permitted to do. The mechanism through which these decisions are made is the authorization model. Several models are in use, each appropriate to different contexts.

Principal authorization models
Model	How decisions are made	Typical use
DAC Discretionary Access Control	Resource owners decide who may access their resources. Access is granted at the owner's discretion.	File systems; collaboration platforms; environments where user autonomy is valued.
MAC Mandatory Access Control	Access decisions are determined by system policy based on classification labels. Users cannot change access decisions.	Government and defence; environments with strict classification requirements.
RBAC Role-Based Access Control	Access is granted based on the subject's role. Entitlements are grouped into roles; subjects are assigned roles.	Most enterprise environments; business applications; environments where job functions map to defined access patterns.
ABAC Attribute-Based Access Control	Access decisions are based on attributes of the subject, resource, action, and environment, evaluated against policies.	Complex environments; cloud-native architectures; contexts requiring fine-grained or context-aware authorization.
ReBAC Relationship-Based Access Control	Access decisions are based on the relationships between subjects and resources — for example, "owner of", "member of", "shared with".	Collaboration platforms; social applications; content management; environments where relationships are central.

Discretionary access control

DAC is the oldest and simplest model. Resource owners control access to their resources — they decide who may access them and with what permissions. The model is intuitive and gives users autonomy, but it scales poorly and provides limited assurance: users may grant access inappropriately, and there is no centralised control over who can access what.

Mandatory access control

MAC inverts the DAC model. Access decisions are determined by system policy based on classification labels — a subject with clearance at a given level can access resources at that level, and this is enforced by the system regardless of individual preferences. MAC is used in government and defence contexts where classification is formal and strict, and where individual discretion is inappropriate.

Role-based access control

RBAC is the dominant authorization model in enterprise environments. Access is granted based on the subject's role — a collection of entitlements associated with a job function or responsibility. Subjects are assigned roles; entitlements are assigned to roles. Authorization decisions evaluate whether the subject's roles include the entitlement required for the access request.

Attribute-based access control

ABAC evaluates access decisions based on attributes — properties of the subject (department, clearance, location), the resource (classification, owner, sensitivity), the action (read, write, delete), and the environment (time, device posture, network). Policies define the conditions under which access is granted; decisions are evaluated against those conditions at the time of access.

ABAC is more expressive than RBAC but also more complex. It enables fine-grained authorization and context-aware decisions — for example, "grant access if the subject is in the finance department, the request is during business hours, and the device is managed." This flexibility comes at the cost of policy complexity, testing requirements, and the need for accurate attribute data.

Relationship-based access control

ReBAC evaluates access based on relationships between subjects and resources. A subject may access a resource because they are its owner, because they are a member of a group that has been granted access, or because they have been explicitly shared with. ReBAC is common in collaboration platforms, content management systems, and social applications where the relationship between users and content is the natural basis for access decisions.

Models combine in practice

In enterprise environments, most systems combine models. A cloud platform might use RBAC for base access, ABAC for policy refinements based on resource tags and request context, and ReBAC for sharing relationships. The choice is not which model to adopt but which models to combine, and how.

08 RBAC and ABAC in depth

RBAC and ABAC are the two most consequential authorization models for enterprise practice. The comparison between them is one of the most frequently encountered decisions in access-control design.

RBAC in depth

RBAC organises entitlements into roles that reflect business functions. Users are assigned roles; roles carry entitlements. Authorization evaluates whether the subject's roles include the entitlement required for the access.

RBAC has several variants:

Flat RBAC. Users are assigned roles; roles carry permissions. The simplest variant, and the most common.
Hierarchical RBAC. Roles inherit from other roles. A "senior manager" role might inherit from "manager", which inherits from "employee". Hierarchy reduces role proliferation but requires careful design.
Constrained RBAC. Separation-of-duties constraints are applied — certain role combinations are forbidden. Used where the segregation of duties is required.
Symmetrical RBAC. Permissions can be reviewed from either direction — which roles grant a permission, and which permissions a role grants. Supports access review and role engineering.

RBAC's principal strengths are simplicity and manageability. Roles are intuitive — they reflect job functions — and access reviews can be conducted at the role level rather than at the individual entitlement level. For environments where access patterns map cleanly to job functions, RBAC provides an effective and administrable model.

RBAC's principal weaknesses emerge in complex or dynamic environments:

Role explosion. In organisations with diverse access requirements, the number of roles required to represent all the combinations can grow unwieldy. Some enterprises have thousands of roles, which undermines the manageability that motivated RBAC in the first place.
Role granularity trade-offs. Broad roles over-grant access; fine-grained roles proliferate. Finding the right balance is difficult and ongoing.
Context insensitivity. RBAC decisions do not consider context — time, device, location, resource attributes. Access granted by a role is granted regardless of these factors.
Role drift. Over time, roles accumulate entitlements that were added for specific purposes and never removed, producing the same privilege-creep problem at the role level that affects individual accounts.

ABAC in depth

ABAC evaluates access decisions based on attributes. A policy defines the conditions under which access is granted; the decision is evaluated at access time based on the current values of the relevant attributes.

A typical ABAC policy might be expressed as: "Grant access to a resource if the subject's department matches the resource's owning department, the subject's clearance level is at least the resource's classification, the request occurs during business hours, and the subject's device is managed and compliant."

ABAC's principal strengths are expressiveness and context-awareness:

Fine-grained control. ABAC can express policies that RBAC cannot — policies based on resource attributes, environmental conditions, or complex combinations of factors.
Context-awareness. Access decisions can consider device posture, network location, time, and other environmental attributes.
Reduced role proliferation. Because decisions are based on attributes rather than roles, ABAC can express complex access patterns without requiring a corresponding proliferation of roles.
Dynamic policies. Policies can reflect changes in attributes without requiring role reassignment. A change in department affects access decisions automatically.

ABAC's principal weaknesses are complexity and dependency on data:

Policy complexity. ABAC policies can become complex and difficult to reason about. Testing and verification are correspondingly more demanding.
Attribute accuracy. ABAC depends on accurate, current attributes. Inaccurate attributes produce incorrect access decisions — either over-granting or under-granting access.
Attribute source governance. Each attribute has a source, and the reliability of that source determines the reliability of the decision. Governance of attribute sources is essential.
Administrative complexity. Designing ABAC policies requires skills that are less widely distributed than RBAC administration.
Review challenges. Access reviews are less straightforward in ABAC — there is no role to review, only policies and attributes.

Choosing between RBAC and ABAC

RBAC and ABAC compared
Dimension	RBAC	ABAC
Decision basis	Roles assigned to subjects	Attributes of subject, resource, action, environment
Expressiveness	Moderate	High
Context-awareness	Limited	High
Administrative complexity	Moderate; role design is the main challenge	High; policy design and attribute management are both challenging
Scalability	Good for stable access patterns; degrades with complexity	Better for complex environments, provided attributes are well governed
Access review	Role-based review is tractable	Policy and attribute review required; less intuitive
Data dependency	Role assignments only	Attribute sources, accuracy, and governance
Typical use	Enterprise applications; stable access patterns; environments where job function is the natural basis	Cloud-native architectures; fine-grained authorization; context-aware decisions

In practice, most enterprises use both. RBAC provides the base access model — who the subject is, broadly, and what their role entitles them to access. ABAC provides the refinements — decisions that depend on context, resource attributes, or environmental conditions. Hybrid models are common, and increasingly considered best practice.

Worked example — RBAC and ABAC in a healthcare enterprise

A healthcare enterprise must control access to patient records. Different roles require different levels of access, and additional constraints apply.

RBAC base:

Clinician role. Can access records of patients under their care.
Nurse role. Can access records of patients on their ward.
Administrative role. Can access billing-related fields but not clinical notes.
Researcher role. Can access de-identified data for approved research.

ABAC refinements:

Access to a record is granted only if the subject's role permits it and the subject has a legitimate treatment relationship with the patient (relationship attribute).
Access is granted only during the subject's working hours unless an emergency override applies (environmental attribute).
Access to particularly sensitive records (mental health, substance abuse) requires an additional attribute indicating specific authorisation.
Access from unmanaged devices is restricted to read-only, even for authorised roles (device attribute).

The example illustrates the hybrid pattern. RBAC provides the base structure; ABAC provides the constraints that reflect clinical, ethical, and regulatory requirements that cannot be expressed through roles alone.

09 Comparing and selecting models

Selecting an authorization model requires balancing expressiveness against complexity, and matching the model to the access patterns the enterprise actually needs to support.

Selection criteria

Criteria for selecting an authorization model
Criterion	What to consider
Access pattern stability	Stable patterns favour RBAC; dynamic or complex patterns favour ABAC.
Context sensitivity required	If decisions must depend on time, device, location, or resource attributes, ABAC is necessary.
Regulatory requirements	Some regulations require specific access controls — separation of duties, least privilege, need-to-know — that influence model selection.
Scale of the environment	Very large environments may struggle with RBAC role proliferation; well-governed ABAC can scale better.
Attribute availability and quality	ABAC requires reliable attributes. If attribute sources are unreliable, RBAC may be more pragmatic.
Administrative capability	ABAC requires more sophisticated administration. Enterprises without the capability should adopt a simpler model initially.
Platform support	The models supported by the enterprise's platforms and applications determine what is feasible.
Review tractability	Access review is more tractable under RBAC. ABAC review requires more sophisticated tooling.

Implementation models

Authorization decisions must be enforced somewhere. Three common implementation models are relevant:

Local enforcement. Each application enforces its own authorization decisions. Simple but difficult to keep consistent across applications, and prone to gaps.
Centralised enforcement (PDP/PEP). A central policy decision point (PDP) evaluates decisions based on a central policy store, and policy enforcement points (PEPs) in applications enforce the decisions. Provides consistency but introduces dependency and performance considerations.
Externalised authorization. Authorization decisions are delegated to a specialised external service. Common in modern microservices architectures and in cloud-native environments. Provides consistency and separation but introduces a dependency on the external service.

Modern architectures increasingly favour externalised authorization — services such as OPA (Open Policy Agent), AWS Cedar, and commercial alternatives — because they centralise policy management while supporting distributed enforcement. This pattern aligns well with Zero Trust, examined in Lesson 2.7.

The most useful principle

Choose the simplest model that meets the enterprise's requirements. Complex authorization that is poorly implemented is worse than simple authorization that is well implemented. ABAC's expressiveness is valuable only if the enterprise has the capability to design, test, and review policies rigorously. Where that capability is absent, RBAC — well-designed and well-governed — is likely to produce better outcomes.

10 Enterprise practice and failures

Authentication and authorization failures recur across enterprises. Recognising the patterns accelerates assessment and informs improvement.

Authentication failure patterns

Password-only authentication for high-value access. Even where MFA is deployed for most users, administrative and service accounts are sometimes left with password-only authentication.
Weak MFA mechanisms. SMS-based MFA deployed for high-value accounts where phishing-resistant MFA is warranted.
Trivially bypassable MFA fallbacks. Strong MFA undermined by weak reset or recovery mechanisms.
No MFA for service accounts. Non-human identities with passwords that are never rotated and cannot support MFA.
Session tokens that never expire. Sessions that persist indefinitely, allowing captured tokens to be used indefinitely.
Inability to invalidate sessions. Stateless tokens that cannot be revoked before expiry, providing a window during which a compromised token remains valid.

Authorization failure patterns

Over-permissive roles. Roles that grant access beyond what the role's function requires, often the result of role accumulation over time.
Role explosion. Thousands of roles that cannot be maintained or reviewed consistently.
Missing enforcement. Authorization policies that exist but are not enforced consistently across all access paths — particularly APIs, direct database access, and administrative interfaces.
Direct object references. Applications that grant access to a resource based on a client-supplied identifier, without verifying that the subject is authorised to access that resource. A common source of data exposure.
Trusting client-supplied data. Applications that accept authorization-relevant data from clients — role claims, user identifiers — without verification, allowing clients to assert access they do not have.
Inconsistent enforcement across services. In distributed systems, different services applying different rules, producing access paths that bypass the intended controls.
Entitlement accumulation at the role level. The same privilege-creep pattern that affects individual accounts, applied at the role level.

Documented failures and lessons

Several well-documented incidents illustrate how authentication and authorization failures manifest in practice.

Authentication failures at scale. Large credential breaches — through compromise of a service that stores passwords or through large-scale phishing — have demonstrated the consequences of password-only authentication and of weak credential storage. Credential stuffing attacks against services with password-only authentication have produced substantial account compromise across many enterprises.

MFA bypass through session hijacking. Sophisticated adversary-in-the-middle phishing frameworks have demonstrated that MFA alone is not sufficient if session tokens can be captured and reused. Enterprises that deployed MFA and did not address session security discovered that attackers could bypass their MFA by hijacking sessions after authentication had completed.

Authorization failures through direct object references. Many documented breaches have involved applications that granted access to records based on identifiers supplied by the client, without verifying that the requesting subject was authorised to access those records. This pattern is common in applications developed without adequate security review.

Over-permissive cloud roles. Cloud breaches have repeatedly involved roles that granted broader access than intended — sometimes administrator-level access granted for convenience, sometimes roles that accumulated entitlements over time. Cloud providers now offer tools to identify over-permissive roles, but adoption varies.

Authentication and authorization failure patterns
Failure pattern	Primary lesson
Password-only authentication for high-value access	MFA should be universal, including for administrative and service accounts.
Weak MFA mechanisms	Phishing-resistant MFA is warranted where the threat justifies it.
Trivially bypassable MFA fallbacks	Fallback mechanisms must be at least as strong as the primary mechanism.
Sessions that cannot be invalidated	Session management must include server-side invalidation.
Over-permissive roles	Roles should be reviewed and refined regularly.
Missing authorization enforcement	Enforcement must be consistent across all access paths.
Direct object references	Authorization must be verified on the server, not trusted from the client.
Trusting client-supplied data	Clients cannot be trusted to assert their own authorization.

The most consequential pattern

Of all the patterns in this lesson, the most consequential in practice is the combination of strong authentication with weak authorization. An enterprise that deploys MFA and SSO but leaves over-permissive roles and missing enforcement in place has addressed the front door and left the interior open. Attackers who gain a foothold — through any means — find that the enterprise's internal controls do not limit what they can reach.

11 Key concepts

The terms below are used throughout the course. Capture them in your own words as you work through the lesson.

Authentication: The process of establishing that a subject is who they claim to be. Answers the question "who is this?". Implemented through credentials and identity assertions.
Authorization: The process of determining what an authenticated subject is permitted to do. Answers the question "what may they do?". Implemented through access-control models and policies.
Authentication factor: A category of evidence used to establish identity — something you know (knowledge), something you have (possession), something you are (inherence), something you do (behaviour).
Multi-factor authentication (MFA): Authentication requiring evidence from two or more distinct factors. Substantially improves resistance to credential-based attacks compared with single-factor authentication.
One-time password (OTP): A single-use code that expires quickly, used as an authentication factor. Implemented through hardware tokens, authenticator apps (TOTP), SMS delivery, or push notifications.
FIDO2 / WebAuthn: Standards for phishing-resistant authentication using public-key cryptography bound to a specific origin. The private key remains in a hardware or platform authenticator; no credential is transmitted.
Phishing-resistant authentication: Authentication that cannot be defeated by phishing because the credential is bound to a specific origin and cannot be replayed. Provided by FIDO2 and certificate-based authentication.
MFA fatigue: An attack in which the attacker repeatedly triggers MFA prompts until the user approves one to stop the prompts. Mitigated by number matching, rate limiting, and user education.
Adversary-in-the-middle (AiTM) phishing: A phishing technique that proxies the legitimate service, capturing credentials and MFA codes, and the session token, allowing the attacker to continue the session. Defeated by phishing-resistant authentication.
Single sign-on (SSO): The property that a subject authenticates once and gains access to multiple applications without re-authenticating. Enabled by federation.
Session: The period during which a subject's authenticated state persists. Managed through session tokens presented with subsequent requests.
Session token: A credential issued at authentication and presented with subsequent requests to maintain the authenticated session. Common formats include cookies, JWTs, and opaque bearer tokens.
Session invalidation: The termination of a session before its natural expiry — on logout, password change, administrative action, or suspicious activity. Server-side invalidation is essential; without it, a captured token remains valid until expiry.
Access-control model: The mechanism through which authorization decisions are made. Principal models include DAC, MAC, RBAC, ABAC, and ReBAC.
Discretionary access control (DAC): Access decisions made by resource owners at their discretion. Simple and intuitive but scales poorly and provides limited assurance.
Mandatory access control (MAC): Access decisions determined by system policy based on classification labels. Users cannot change decisions. Used in government and defence contexts.
Role-based access control (RBAC): Access decisions based on the subject's role. Entitlements are grouped into roles; subjects are assigned roles. The dominant model in enterprise environments.
Attribute-based access control (ABAC): Access decisions based on attributes of the subject, resource, action, and environment, evaluated against policies. More expressive than RBAC but more complex and more dependent on attribute data.
Relationship-based access control (ReBAC): Access decisions based on relationships between subjects and resources — ownership, membership, sharing. Common in collaboration and content platforms.
Role explosion: The proliferation of roles to the point where the model becomes unmanageable. A common failure mode in large RBAC deployments.
Policy decision point (PDP) / policy enforcement point (PEP): Architectural components in centralised authorization. The PDP evaluates access decisions based on policy; PEPs in applications enforce the decisions.
Direct object reference: An application pattern in which access to a resource is granted based on a client-supplied identifier without verifying the subject's authorization to access that resource. A common source of data exposure.
Separation of duties: The principle that combinations of entitlements that would allow a single subject to complete a sensitive operation alone should be prevented. Often enforced through constrained RBAC.

12 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 1. They are not graded, but completing them will improve the quality of your forum contribution.

Activity 1 — Authentication mechanism assessment

For an enterprise context you know well, assess the authentication mechanisms in use:

for standard users, administrators, and service accounts;
which factors and mechanisms are used in each case;
which mechanisms are phishing-resistant and which are not;
how MFA fallbacks and recovery are handled;
how sessions are managed, including invalidation.

Reflect on the results: which users or accounts have weaker mechanisms than their risk justifies? What are the highest-priority improvements?

Activity 2 — Authorization model design

Choose an enterprise context and design an authorization model (400–500 words) that addresses:

whether the environment is better suited to RBAC, ABAC, or a combination;
the roles or attribute schemes required to represent the access patterns;
how separation of duties would be enforced where required;
how enforcement would be implemented (local, centralised, or externalised);
how access would be reviewed;
the main risks in the design and how they would be mitigated.

Support your design with reference to the lesson material and to published guidance (NIST SP 800-162 for ABAC, NIST RBAC standard, or equivalent).

Activity 3 — Preparing for Forum 2 and Assignment 1

Forum 2 includes discussion of MFA effectiveness, IAM challenges, and Zero Trust adoption. Assignment 1 includes technical questions on evaluating authentication mechanisms and analysing how Zero Trust contributes to confidentiality, integrity, availability, and accountability.

Review the Forum 2 prompts and the Assignment 1 brief, and note how the material from this lesson — particularly the MFA bypass techniques, the RBAC-versus-ABAC comparison, and the session management considerations — will strengthen your analysis.

13 Self-check

Answer the questions below before moving to Lesson 2.7. If you cannot answer a question confidently, revisit the corresponding section.

14 Summary

This lesson has examined authentication and authorization — the two decisions through which identity infrastructure becomes access control. The essential points are:

Authentication and authorization are distinct. Authentication establishes who a subject is; authorization determines what they may do. They have different failure modes and require different controls.
Authentication relies on factors. Something you know (weakest), something you have, something you are, and something you do. MFA requires evidence from distinct factors; two passwords are not MFA.
Authentication mechanisms vary widely in strength. Passwords alone are weak; SMS OTP is discouraged; authenticator apps and hardware tokens are stronger; FIDO2 and certificate-based authentication are phishing-resistant.
MFA can be bypassed. Real-time phishing, MFA fatigue, SIM swapping, session hijacking, and adversary-in-the-middle attacks. The choice of MFA mechanism matters as much as the decision to deploy it.
Sessions are where authentication persists. Session lifetime, token storage, invalidation, and binding all affect the security of the authenticated state. The inability to invalidate sessions is a consequential weakness.
Authorization is implemented through access-control models. DAC, MAC, RBAC, ABAC, and ReBAC. Each is appropriate to different contexts.
RBAC is the dominant enterprise model. Roles reflect job functions; entitlements are assigned to roles. Simple and manageable but susceptible to role explosion and role drift.
ABAC is more expressive but more complex. Attribute-based decisions are context-aware and fine-grained but depend on reliable attribute data and require more sophisticated policy design.
Hybrid models are common. RBAC for base access, ABAC for refinements, ReBAC for relationships. The choice is not which model to adopt but which to combine and how.
Failure patterns recur. Password-only authentication for high-value accounts; weak MFA fallbacks; sessions that cannot be invalidated; over-permissive roles; missing enforcement; direct object references. Recognising these patterns accelerates improvement.

These ideas prepare for Lesson 2.7, which develops Zero Trust — the architectural paradigm that places authentication and authorization at the centre of every access decision, regardless of network location.

Before moving on

Make sure you can distinguish authentication from authorization, describe the factors of authentication, explain how MFA can be bypassed, compare RBAC and ABAC, and identify at least five failure patterns from Section 9. If you cannot yet do all five, revisit Sections 1, 4, 7, and 9.

Next lesson

Lesson 2.7 — Zero Trust Principles examines the architectural paradigm that places identity and continuous verification at the centre of enterprise security — the culmination of the identity, cryptographic, and access-control material from the whole unit.