Identity, Authentication and Access Control

Introduction and Context

Identity and access management (IAM) is the security discipline concerned with establishing who or what is requesting access, determining what that subject may do, and enforcing those decisions throughout the lifetime of an account and session. In web and application security, IAM is not limited to a login screen. It includes identity proofing, account creation, credential management, authentication, authorisation, session control, recovery, monitoring, revocation and eventual account deletion.

A useful distinction is:

• Identification is the claim of an identity, such as a username or email address.
• Authentication is the process of verifying that claim.
• Authorisation is the decision about what an authenticated subject may access or perform.
• Accountability is the ability to associate actions with a subject through logging and evidence.

A system can authenticate users correctly and still be insecure. For example, an application may verify Alice's password but allow her to retrieve Bob's invoice by changing an identifier in the URL. This is an authorisation failure, commonly associated with insecure direct object references or broken object-level authorisation.

Modern applications also operate across browsers, mobile clients, APIs, microservices, cloud platforms and third-party identity providers. Consequently, identity security requires both technical controls and governance. The central design principle is least privilege: a subject should receive only the permissions necessary for an approved purpose, for only as long as necessary.

Learning Objectives

By the end of this chapter, students should be able to:

1. Design an identity lifecycle from enrolment to account deletion.
2. Explain password, passwordless and multi-factor authentication.
3. Evaluate authentication factors, risks and assurance levels.
4. Design secure session management and account recovery.
5. Compare RBAC, ABAC, OAuth 2.0, OpenID Connect and SAML.
6. Analyse common identity attacks and appropriate mitigations.
7. Apply governance, privacy and monitoring requirements to IAM solutions.

Identity Lifecycles

An identity lifecycle begins before an account is created and ends after access has been completely revoked and relevant records have been retained or securely destroyed. A typical lifecycle contains the following stages:

1. Identity proofing and enrolment: The organisation establishes that an applicant is a real and appropriate person, service or device. The required evidence depends on risk. A public discussion forum may require only email verification; a banking service may require regulated identity checks.
2. Provisioning: An account, identifiers, authenticators and initial permissions are created. Provisioning should be automated where possible and linked to an authoritative source such as a human-resources or student-information system.
3. Use and maintenance: Attributes, roles, authenticators and contact details are updated. Changes should be authenticated, authorised and auditable.
4. Access review: Managers, application owners or automated policies periodically verify that permissions remain justified.
5. Suspension and revocation: Lost devices, suspected compromise, disciplinary action or employment termination should trigger rapid suspension and token invalidation.
6. Deprovisioning: Accounts, API keys, sessions, recovery methods, group memberships and delegated access are removed or disabled.
7. Retention and disposal: Audit records are retained according to legal, contractual and operational requirements, then securely disposed of.

A common failure is the orphaned account: an account belonging to a former employee, contractor or service that remains active. Joiner–mover–leaver processes reduce this risk. A mover event is particularly important because changing departments may require removal of old privileges, not merely addition of new ones.

Identity Governance

Identity governance assigns ownership and accountability. Each important application should have an owner responsible for defining access requirements, while business managers approve access for their staff. Security teams define control standards, and auditors verify evidence. Separation of duties prevents one person from requesting, approving and implementing their own high-risk access.

Service and machine identities require the same discipline as human identities. They should have named owners, narrow permissions, credential rotation, expiry dates and monitoring. Hard-coded secrets in source code are unacceptable because they may be copied into repositories, build logs and backups.

Authentication Factors and Assurance

Authentication factors are commonly grouped into three categories:

A fourth category, sometimes called location or context, includes network location, device posture and behavioural signals. Context can strengthen risk assessment but is usually not a substitute for an independent primary factor. Two entries from the same category do not necessarily provide true multi-factor authentication; two passwords remain knowledge factors.

Authentication assurance depends on more than the number of factors. It also depends on resistance to phishing, the quality of identity proofing, authenticator protection, recovery processes, device security and the consequences of compromise. A biometric characteristic is not a secret and cannot normally be changed after disclosure. Biometrics are therefore best used as a local activation factor for a protected device or cryptographic key, rather than as a database password.

Password Authentication

Passwords remain widespread because they are inexpensive and familiar, but they are vulnerable to guessing, credential stuffing, phishing, keylogging, reuse and breaches of poorly protected databases.

A secure password design should:

• permit long passwords and passphrases;
• avoid arbitrary composition rules that encourage predictable substitutions;
• compare new passwords against breached-password lists;
• rate-limit failed attempts and detect distributed attacks;
• avoid periodic forced changes unless compromise is suspected;
• prevent reuse of recent passwords where appropriate;
• never send passwords by email or store them in plaintext.

Password Storage

A password verifier should store a password-derived value produced by a slow, memory-hard password hashing function, together with a unique salt and configuration parameters. The salt prevents identical passwords from producing identical stored values and makes precomputed rainbow-table attacks ineffective. A password hash is not encryption: it is not intended to be decrypted.

A simplified verification process is:

Here, v is the stored verifier, password is the candidate password, salt is a unique non-secret random value, and cost represents work and memory parameters. During login, the submitted password is processed using the stored parameters and compared using a suitable constant-time comparison. The function should be an established password KDF such as Argon2id, scrypt or an appropriately configured PBKDF2 implementation. A separate server-side pepper may provide additional defence if stored securely outside the database.

The KDF does not make weak passwords strong. It increases the cost of testing guesses after a database breach. Password verification should also be protected by throttling, monitoring and MFA.

Passwordless Authentication

Passwordless authentication replaces a memorised secret with a cryptographic authenticator or another approved mechanism. FIDO2 and WebAuthn use public-key cryptography. During registration, the authenticator creates a key pair. The private key remains protected by the authenticator, while the application stores the public key. During authentication, the server sends a challenge; the authenticator signs it, and the server verifies the signature.

The challenge must be fresh and bound to the intended relying party. WebAuthn's origin binding helps prevent a credential created for one website from being used successfully at a fraudulent origin. This makes properly implemented passkeys substantially more resistant to phishing than passwords or one-time codes entered into a fake site.

Passwordless systems still require careful recovery. If users can bypass a strong passkey using a weak email link or support-desk process, the weaker recovery path becomes the effective authentication method.

Multi-Factor Authentication

MFA requires at least two independent authentication factors. Strong choices include hardware security keys and authenticator applications using time-based one-time passwords (TOTP). SMS codes are better than passwords alone in some contexts but are vulnerable to SIM swapping, number recycling, malware and social engineering; they should not be treated as equivalent to phishing-resistant authenticators.

MFA fatigue attacks bombard a user with approval requests until the user accepts one. Number matching, clear transaction context, rate limits and user education reduce this risk. High-risk actions should use step-up authentication and, where feasible, transaction signing that binds approval to the specific action and amount.

Session Management

Authentication establishes a session; it does not continuously prove identity. A session token is therefore a high-value bearer credential. If stolen, it may allow access without the password or MFA.

Secure web sessions should use unpredictable, high-entropy identifiers generated by a cryptographically secure random generator. Tokens should be transmitted only over HTTPS and stored in cookies with appropriate attributes:

• Secure: send only over encrypted connections;
• HttpOnly: prevent ordinary client-side scripts from reading the cookie;
• SameSite: reduce cross-site request risks, selected according to application requirements;
• narrow domain and path scope;
• appropriate expiration and idle timeouts.

Applications should regenerate the session identifier after login and privilege changes to prevent session fixation. Logout should invalidate the server-side session or refresh-token family, not merely delete a browser value. Sensitive operations may require reauthentication, even during an otherwise valid session.

Session policy should distinguish idle timeout, absolute lifetime and risk-based termination. A long-lived refresh token should be protected more carefully than a short-lived access token. Rotation and reuse detection can reveal token theft: if an invalidated refresh token is presented again, the associated token family may be revoked.

Cross-site request forgery (CSRF) is an authorisation abuse in which a victim's browser sends an unwanted state-changing request with ambient credentials. SameSite cookies, anti-CSRF tokens and origin checks are common defences. XSS can defeat many browser controls, so output encoding and content-security controls remain essential.

Authorisation Models

Authentication answers “who?”; authorisation answers “what is this subject allowed to do, to which object, under which conditions?” Every sensitive request should be authorised on the server. Hiding buttons in a user interface is not an access control mechanism.

Role-Based Access Control

RBAC assigns permissions to roles, and users or service identities receive roles. For example, a hospital application might define Nurse, Physician and Billing-Clerk roles. RBAC is understandable and auditable, particularly where job functions are stable.

Its weaknesses include role explosion, excessive privilege and difficulty representing contextual decisions. A user may be a physician but should not access records outside an assigned clinic or after an emergency assignment ends. RBAC therefore often requires constraints, inheritance and separation-of-duty rules.

Attribute-Based Access Control

ABAC evaluates attributes of the subject, resource, action and environment. A policy might state: a clinician may read a patient's record if the clinician is assigned to the patient, the purpose is treatment, the device is managed and the request occurs during an approved session.

ABAC offers fine-grained and contextual control, but policies can become difficult to understand, test and govern. Attribute quality is critical: a stale department attribute can produce an incorrect decision. Policy decision points should be separated from policy enforcement points, and decisions should be explainable and logged.

A mature architecture may combine models: roles provide broad eligibility, while attributes and relationships impose context-specific restrictions. Deny-by-default, least privilege and fail-safe behaviour should guide policy evaluation.

OAuth 2.0, OpenID Connect and SAML

These technologies solve related but different problems.

OAuth 2.0 is an authorisation framework. It allows a resource owner to delegate limited access to a client through an authorisation server. An access token represents granted authority to a resource server. OAuth does not, by itself, authenticate the end user to the client.

For browser-based applications, the authorisation-code flow with Proof Key for Code Exchange (PKCE) is the preferred modern pattern. The client receives an authorisation code, and the token endpoint exchanges it after verifying the code verifier. Redirect URIs must be exact or tightly controlled; state protects request correlation and helps prevent login CSRF. Tokens should have limited scope, audience and lifetime.

OpenID Connect (OIDC) is an identity layer built on OAuth 2.0. It provides an ID token, normally a signed JSON Web Token, containing claims about the authentication event and subject. The client must validate the issuer, signature, audience, expiry, nonce and relevant claims. An ID token is intended for the client; it should not automatically be presented to an API as an access token.

SAML is an XML-based federation standard widely used in enterprise single sign-on. An identity provider issues assertions to a service provider. Secure deployments validate signatures, issuer, audience, recipient, timestamps and assertion conditions. XML parsing and signature-wrapping weaknesses demonstrate why mature libraries and strict validation are necessary.

Account Recovery and Identity Attacks

Recovery is an alternative authentication channel and must be designed to the same assurance level as the account itself. Safe recovery practices include verified recovery factors, single-use short-lived tokens, rate limiting, notifications, support procedures with strong identity proofing and delayed high-risk changes where appropriate. Security questions based on public information are weak and should not be relied upon.

Important identity attacks include:

• Credential stuffing: automated reuse of breached username–password pairs. Defences include MFA, breached-password screening, bot detection, rate limiting and breached-credential monitoring.
• Password spraying: trying a small number of common passwords across many accounts. Per-account lockout alone may be ineffective; monitor distributed patterns and use risk-based controls.
• Phishing: deception to capture credentials, codes or approvals. Phishing-resistant cryptographic authentication is the strongest technical response.
• Session hijacking: theft or misuse of a valid session token. Use TLS, secure cookie controls, token rotation, endpoint protection and anomaly detection.
• Session fixation: forcing a known session identifier before login. Regenerate identifiers after authentication.
• MFA bypass: exploiting weak recovery, OAuth misconfiguration, push fatigue or stolen browser sessions. Test the entire authentication journey, not only the login form.
• Privilege escalation: obtaining permissions beyond those approved, often through insecure direct object references, misconfigured roles or stale group membership.
• Enumeration: revealing whether an account exists through different messages or timing. Use consistent responses where practical, while balancing usability and fraud detection.

Monitoring, Testing and Metrics

IAM controls require evidence. Useful logs include authentication success and failure, MFA changes, recovery events, token issuance and revocation, privilege changes, administrative actions and policy decisions. Logs should contain a correlation identifier, subject, action, target, time, result and source context, while avoiding unnecessary secrets and sensitive personal data.

Detection engineering should identify impossible travel cautiously, unusual device changes, abnormal access volume, repeated MFA denials, dormant-account use and privilege changes followed by sensitive downloads. Automated risk scores should support—not silently replace—well-governed decisions. False positives can create denial of service and encourage unsafe workarounds.

Useful measures include the proportion of privileged accounts using phishing-resistant MFA, time to revoke leaver access, number of orphaned accounts, unauthorised access incidents, recovery-channel failures and completion of access reviews. Metrics should measure control effectiveness rather than merely activity volume.

Testing should include unit tests for policy rules, integration tests for federation flows, negative tests for token validation, penetration testing, access reviews and attack simulations. Test cases should explicitly cover horizontal access (one user's data accessed by another user) and vertical access (a lower-privilege user invoking an administrator function).

Case Study: Federated Access for a University Research Platform

The following is an illustrative case.

Background

A university research platform serves students, faculty, external collaborators and automated laboratory devices. It originally used local passwords and broad group permissions. Former collaborators retained access, APIs accepted tokens issued for other services, and researchers shared accounts to operate instruments.

Problem

The university needed single sign-on, secure API access, rapid removal of leavers and fine-grained controls for confidential datasets. It also needed to preserve an audit trail showing which individual initiated each laboratory action.

Analysis

Local passwords created duplicated lifecycle processes and inconsistent MFA. Broad groups did not represent project membership or dataset classification. Shared device accounts prevented accountability. The platform also confused authentication claims with API authorisation: an ID token was accepted as if it were an access token.

Approach and Solution

The university adopted OIDC for user authentication through its institutional identity provider and OAuth 2.0 authorisation-code flow with PKCE for browser clients. APIs accepted only access tokens whose issuer, audience, signature, expiry and scopes were validated. Roles represented broad functions such as Researcher and Project-Administrator, while ABAC policies evaluated project membership, dataset classification, device posture and purpose of use.

FIDO2 passkeys were offered for staff and administrators, with TOTP as a transitional option. Laboratory devices received individually managed service identities with certificates, narrow scopes and rotation procedures. Shared human accounts were removed. A joiner–mover–leaver feed disabled institutional access and triggered project-membership review. Recovery required verified institutional channels and generated alerts.

Outcome

The design improved revocation speed, reduced password exposure and associated actions with named users. It also made policy complexity visible: project membership, purpose and dataset classification required authoritative data owners. Regular access reviews and automated tests were introduced to prevent policy drift.

Learning Points

Federation reduces duplicated authentication but does not eliminate authorisation responsibility. Tokens must be validated for their intended audience and purpose. Strong authentication is undermined by weak recovery or shared accounts. Finally, fine-grained policy requires reliable attributes, ownership and continuous review.

Ethical, Legal and Governance Considerations

Identity systems process personal and sometimes biometric data. Organisations should collect only necessary attributes, define retention periods, protect data in transit and at rest, and provide transparent explanations of significant decisions. Biometric systems require particular care because compromise is difficult to reverse and demographic performance may differ across groups.

Access decisions should be reviewable and contestable, especially when automated risk systems block users. Security monitoring must be proportionate: collecting every possible behavioural signal creates privacy, discrimination and insider-threat risks. Regulatory obligations vary by jurisdiction, but principles such as purpose limitation, data minimisation, accountability and breach notification are widely relevant.

Organisations should align controls with recognised guidance, including NIST Digital Identity Guidelines, NIST guidance on password management, OWASP authentication and authorisation guidance, and relevant OAuth, OIDC, WebAuthn and SAML specifications. Standards do not remove the need for threat modelling and application-specific testing.

Contemporary Developments and Best Practices

Passkeys are increasing the practicality of phishing-resistant authentication, while device-bound credentials and hardware-backed key storage improve resistance to token theft. Zero-trust architectures treat authentication as continuous and resource-specific rather than assuming that a trusted network implies trusted users. Continuous authorisation evaluates changing context, but should avoid opaque decisions that cannot be investigated.

AI-assisted fraud detection can identify unusual login patterns, but attackers can also use AI for phishing, deepfake support calls and automated password attacks. AI outputs should be treated as risk signals, not unquestionable identity proof. Human review, documented thresholds, privacy controls and adversarial testing are necessary.

A professional IAM baseline should include:

1. authoritative identity ownership and lifecycle automation;
2. phishing-resistant MFA for privileged and high-risk access;
3. secure password hashing and breached-password screening;
4. deny-by-default, server-side authorisation;
5. short-lived, correctly scoped tokens and secure sessions;
6. exact federation validation and separation of ID tokens from access tokens;
7. strong, monitored recovery procedures;
8. periodic access reviews and rapid revocation;
9. comprehensive but privacy-conscious audit logging;
10. regular negative testing, threat modelling and incident exercises.

Chapter Summary

Identity security is a lifecycle rather than a login feature. Secure systems establish identities appropriately, provision least-privilege access, authenticate with suitable assurance, maintain protected sessions, authorise every sensitive action and revoke access promptly. Passwords require strong KDF-based storage, throttling and breach-aware controls; passkeys and other cryptographic authenticators provide stronger phishing resistance. MFA is effective only when factors are independent and recovery is equally strong.

RBAC is manageable for stable job functions, while ABAC provides contextual precision at the cost of policy and attribute complexity. OAuth 2.0 delegates authorisation, OIDC adds authentication and identity claims, and SAML supports enterprise federation. Correct validation of tokens and assertions is essential. Credential stuffing, phishing, session attacks, recovery abuse and privilege escalation require layered technical, organisational and monitoring controls. Ethical IAM also demands privacy, fairness, accountability and explainable governance.

Key Terms

Authentication: Verification of a claimed identity.

Authorisation: Determination and enforcement of permitted actions.

Identity lifecycle: The stages from identity proofing and provisioning through use, review, revocation and disposal.

MFA: Authentication using at least two independent factor categories.

Passkey: A cryptographic, often phishing-resistant, authentication credential.

Salt: A unique non-secret value combined with a password before derivation.

Password KDF: A deliberately costly function used to derive a password verifier.

Session fixation: An attack in which a victim is induced to use an attacker-known session identifier.

CSRF: Unauthorised state-changing requests sent using a victim's browser credentials.

RBAC: Access control based primarily on roles.

ABAC: Access control based on subject, resource, action and environmental attributes.

Least privilege: Granting only the access necessary for an approved purpose.

OAuth 2.0: A framework for delegated authorisation.

OpenID Connect: An identity layer built on OAuth 2.0.

SAML: An XML-based framework for exchanging federated authentication assertions.

Access token: A credential representing authority to access a protected resource.

ID token: An OIDC token containing claims about an authentication event and subject.

Credential stuffing: Automated use of breached credentials against other services.

Deprovisioning: Removing or disabling identities, credentials and permissions when access is no longer justified.

Review Questions

Short Answer Questions

1. Distinguish identification, authentication and authorisation.
2. Why is a unique salt used in password storage?
3. Name two security attributes appropriate for session cookies.
4. What is the principal difference between OAuth 2.0 and OpenID Connect?
5. Why are shared accounts harmful to accountability?

Long Answer Questions

1. Explain the complete identity lifecycle and identify controls required at each stage.
2. Compare passwords, TOTP, SMS codes, biometrics and passkeys in terms of security and usability.
3. Compare RBAC and ABAC, including situations in which a combined approach is appropriate.
4. Describe secure session management for a modern web application.
5. Explain how a university could use OIDC and OAuth 2.0 without confusing authentication with API authorisation.

Analytical / Application Questions

1. A former contractor can still access a research application three months after leaving. Analyse the lifecycle failures and propose preventive and detective controls.
2. An API accepts an ID token issued for the web client and uses its subject claim to authorise requests. Identify the design errors and describe a secure alternative.
3. A company has frequent MFA-push fatigue incidents but cannot immediately deploy hardware keys. Develop a risk-reduction plan covering authentication, recovery, monitoring, user experience and governance.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorisation?

A. Authentication determines permissions, while authorisation identifies a user.

B. Authentication verifies identity, while authorisation determines permitted actions.

C. Authentication encrypts data, while authorisation hashes passwords.

D. Authentication creates logs, while authorisation deletes accounts.

Correct Answer: B. Authentication verifies identity, while authorisation determines permitted actions.

Question 2

What is the primary purpose of a unique password salt?

A. To make the password recoverable by administrators

B. To prevent identical passwords from producing identical stored values

C. To replace the need for a password KDF

D. To provide multi-factor authentication

Correct Answer: B. To prevent identical passwords from producing identical stored values

Question 3

Which mechanism is generally most resistant to phishing?

A. A password sent by email

B. An SMS one-time code

C. A FIDO2 passkey bound to the relying party

D. A security question

Correct Answer: C. A FIDO2 passkey bound to the relying party

Question 4

Which OAuth 2.0 practice is appropriate for a browser-based public client?

A. Using the authorisation-code flow with PKCE

B. Embedding a client secret in JavaScript

C. Using an ID token as an unrestricted API token

D. Accepting any redirect URI supplied by the client

Correct Answer: A. Using the authorisation-code flow with PKCE

Question 5

What is the main purpose of an OIDC ID token?

A. To contain claims about an authentication event for the client

B. To act as a database encryption key

C. To replace all API access-control checks

D. To store a user's password hash

Correct Answer: A. To contain claims about an authentication event for the client

Question 6

Which action best mitigates session fixation?

A. Displaying the session identifier to the user

B. Regenerating the session identifier after authentication

C. Making the session cookie available to JavaScript

D. Removing all session expiration limits

Correct Answer: B. Regenerating the session identifier after authentication

Question 7

Which access-control model evaluates environmental context such as device posture and time?

A. ABAC

B. Plaintext ACL only

C. Password-based access control

D. Static filename matching

Correct Answer: A. ABAC

Question 8

What is credential stuffing?

A. Trying one common password against many accounts only

B. Reusing breached username-password pairs against other services

C. Encrypting credentials with a salt

D. Rotating a refresh token after use

Correct Answer: B. Reusing breached username-password pairs against other services

Question 9

Which session-cookie attribute prevents ordinary client-side scripts from reading the cookie?

A. Secure

B. SameSite

C. HttpOnly

D. Public

Correct Answer: C. HttpOnly

Question 10

Why must an application validate an OAuth access token's audience?

A. To ensure the token is intended for the receiving resource

B. To calculate the user's password entropy

C. To determine the browser's screen size

D. To convert the access token into an ID token

Correct Answer: A. To ensure the token is intended for the receiving resource