Chapter 3: Authentication: Who are you?

Introduction

A Twitter account-hijacking case shows why authentication depends on people and governance as well as technology, and why failures damage the integrity of digital relationships.

• Authentication as a system problem: Explain why the Twitter breach shows that strong authentication requires sound processes and governance, not just secure technology. Describe how attackers manipulated employees and a help-desk credential reset rather than cracking passwords or exploiting software.
  Why it matters: Protecting a login also means protecting the human and administrative paths that can grant access.
• Integrity of account relationships: Explain how the account takeovers illustrate authentication’s role in preserving the relationship established when an account is created, including the loss of trust when attackers control trusted accounts.
  Why it matters: An account takeover harms not only the account holder but also people who trust what that account represents.
• Limits and safeguards of authentication: Describe the safeguards the introduction draws from the breach: good MFA can make a credential reset insufficient, zero trust calls for renewed credential checks between systems, and high-consequence actions can require special permissions. Explain why reducing opportunities for human override also matters.
  Why it matters: A single credential or human exception should not automatically open every path to sensitive access.

Key terms: authentication, social engineering, phishing, authentication credentials, governance, relationship integrity, verified accounts, multifactor authentication (MFA), zero-trust security model, contingent authorization

3.1 Terminology

Defines precise terms for discussing identity, authentication, and authorization, especially the distinction between a requester and the entity a request concerns.

• Accounts and identifiers: Distinguish an account from its identifier: an account holds information about an entity, while an identifier uniquely identifies that account within a system’s namespace.
  Why it matters: Keeping the stored information separate from the string that identifies it makes later discussions of accounts clearer.
• Principals and subjects: Distinguish the entity making a request from the entity referred to in an account, policy, or decision, including when one acts on behalf of another.
  Why it matters: A request can be made by one entity while concerning another, so the two roles should not be conflated.
• Precise identity language: Explain why the section favors specific terms such as account, identifier, and principal over the broad word identity.
  Why it matters: Precise wording helps keep discussions of authentication and authorization unambiguous.

Key terms: account, identifier, namespace, principal, subject, identity

3.2 Authentication preserves relationship integrity

This section explains how authentication preserves digital relationship integrity, why systems as well as users must be authenticated, and how one compromised relationship can damage others.

• Relationship integrity and authentication: Explain that relationship integrity is technical confidence that the entity using an account is the one that established it, and that reliable authentication supports accurate authorization decisions.
  Why it matters: An access decision can be wrong if the system cannot reliably tell who is using the account.
• Two-sided authentication and TLS: Describe why both the user and the system need to be authenticated, and how a browser uses TLS certificates to check the server it connects to.
  Why it matters: Checking the system helps prevent people from giving credentials to an impersonator.
• Limits of the browser lock: Explain why a TLS browser lock does not by itself prove that a site is the one a person intended to visit.
  Why it matters: A convincing lock icon cannot compensate for connecting to an attacker-controlled look-alike domain.
• Cascading relationship failures: Trace how the Twitter attack spread from compromised administrator authentication to hijacked verified accounts and harmed followers' trust.
  Why it matters: An authentication failure can damage people who depend on a system's assurances even if their own accounts were not the initial point of compromise.

Key terms: relationship integrity, technical confidence, authentication, authorization, two-way street, Transport Layer Security (TLS), certificates, Certificate Authorities (CAs), public key, browser lock

3.3 Digital relationship life cycles

This section explains why managing a digital relationship across its life cycle matters for authentication and authorization, and notes that the phases vary by relationship.

• Digital relationship life cycle management: Explain why the life cycle of a digital relationship matters for authentication and authorization, and why its phases may differ between relationships.
  Why it matters: A relationship that is not kept in step with real-world and system changes can leave access rules or accounts out of date.

Key terms: digital relationships, relationship life cycle, authentication, authorization, orphaned accounts, policy misalignment

3.3.1 Enrollment (discover and co-create)

Enrollment begins a digital relationship through discovery and a shared process of exchanging information and setting up identity details.

• Enrollment discovery and co-creation: Explain the two subphases of enrollment: discovering where or how to begin, and co-creating a digital relationship through participation by both sides. Describe the identifiers, credentials, and attributes involved at the level presented here.
  Why it matters: This distinction makes enrollment easier to understand as the start of a relationship, not merely account creation.

Key terms: enrollment, onboarding, discovery, co-create, identifiers, credentials

3.3.2 Propagate

This section explains why changes to a digital relationship must reach the systems that rely on it and identifies protocols that help keep account state consistent.

• Cross-system relationship synchronization: Explain why creating, updating, or terminating a digital relationship requires propagating changes to relevant systems, and how this supports authentication and authorization decisions.
  Why it matters: An access decision can depend on whether the system has received the latest change to a relationship.
• Propagation protocol roles: Distinguish the roles this section assigns to SCIM, LDAP, SAML, and OIDC in keeping identity information available across systems.
  Why it matters: These examples show that keeping relationships synchronized can involve account management as well as communicating identity information.

Key terms: propagation, digital relationship, current account state, SCIM, LDAP, SAML, SSO, OIDC, identity assertions

3.3.3 Use

The use phase is when authentication verifies an identity relationship, authorization governs permitted actions, and the system keeps checking whether the relationship remains valid.

• Checks during active use: Explain the distinct roles of authentication and authorization during the use phase, and describe why the system should keep checking the relationship's validity.
  Why it matters: Being authenticated does not by itself settle what someone may do or whether their relationship remains valid.

Key terms: use phase, identity relationships, authentication, authorization, contextual signals, policies

3.3.4 Update

This subsection explains how identity relationships are updated and why account recovery can undermine otherwise strong authentication.

• Identity updates and propagation: Describe how changes to a user’s role, credentials, permissions, or other information update the data connected to their identifier and are repropagated to connected systems.
  Why it matters: Connected systems need the current identity state when a relationship changes.
• Account recovery weak link: Explain why account recovery is part of the authentication system and how a less-protected email reset can weaken an otherwise strong authentication setup.
  Why it matters: Strong sign-in protection can be undermined by a weaker way to recover the account.

Key terms: identity relationships, identifier, repropagated, identity state, account recovery, authentication factors, email resets, weak link

3.3.5 Terminate

This section explains why invalid identity relationships must be terminated and why unused identities need regular cleanup.

• Identity relationship termination: Explain when an identity relationship should be revoked and how termination prevents unauthorized access. Describe automated offboarding and cleanup as ways to avoid leaving dormant accounts active.
  Why it matters: An account left active after its relationship ends can still be exploited.
• Account deletion requests: State the deletion right mentioned in the section and distinguish it from the broader security reason to close unused accounts.
  Why it matters: Account cleanup can address both deletion requests and security risks.

Key terms: terminate phase, revoked, orphaned accounts, lingering permissions, automated offboarding, General Data Protection Regulation (GDPR), stale authentication factors

3.4 Enrollment

Enrollment establishes a digital relationship by recording its context and setting up ways to recognize the entity later.

• Enrollment as relationship foundation: Explain why enrollment is more than creating an account: it records the relationship context and sets up credentials so the entity can be recognized later, providing information for authentication and authorization decisions.
  Why it matters: Enrollment determines what the system can remember about a relationship and how it can recognize the person again.

Key terms: enrollment, digital relationship, credentials, authentication, authorization

3.4.1 Self-service vs. admin-driven enrollment

This section contrasts self-service and administrative enrollment and explains the relationship both create.

• Enrollment initiation and setup: Distinguish self-service from administrative enrollment by who initiates and manages it, how discovery happens, and who typically selects the identifier.
  Why it matters: The two paths assign responsibility for starting and setting up a digital relationship differently.
• Administrative credential handoff: Describe how initial authentication credentials are assigned and handed to an enrollee in administrative enrollment, including the distinction the section makes about first-sign-in changes.
  Why it matters: The initial credential handoff is part of how an administrator-created account becomes usable by its enrollee.
• Shared enrollment outcome: Explain what both enrollment paths produce and the roles of the identifier, authentication, and attributes in that result.
  Why it matters: The setup paths differ, but both establish the same basic kind of digital relationship.

Key terms: self-service enrollment, administrative enrollment, discovery, identifier, initial authentication credentials, out-of-band process, first sign-in, digital certificates, relationship, authentication

3.4.2 Identity proofing and assurance

This section explains how identity proofing sets assurance during enrollment, why the required rigor varies by risk, and why proofing is difficult to trust across organizations.

• Proofing and assurance levels: Explain that identity proofing verifies an entity during enrollment and that the required level of assurance depends on the digital relationship’s risk and requirements. Describe how regulation can require more stringent proofing.
  Why it matters: Enrollment should verify identity strongly enough for the relationship’s risks and obligations.
• Limits of proofing trust: Explain why an organization’s identity-proofing assurance is not purely a matter of technical confidence and why another organization cannot readily rely on its proofing.
  Why it matters: A technically sound identity system does not, by itself, establish that another organization’s enrollment checks can be trusted.

Key terms: identity proofing, level of assurance, Identity Assurance Levels, IAL2, Know Your Customer, technical confidence, legal agreements, trust frameworks

3.4.3 Relationship context and boundaries

This section explains how enrollment records the context and boundaries of a relationship, giving authentication and access control different information to use.

• Authentication and relationship context: Distinguish the confidence that a requester is the enrolled person from the relationship context that determines the boundaries of their access. Explain why Charlie’s strong authentication does not make him an employee.
  Why it matters: A reliable login does not, by itself, establish what access a person should receive.
• Individual and organization accounts: Describe how the supplier enrollment linked an individual account to an organization account, while treating their credentials and identity proofing differently.
  Why it matters: The supplier example shows that enrollment can establish relationships between identities, not just create a login.
• Access needs shape enrollment: Explain how the supplier system’s access-control needs and policy shaped enrollment, including account separation and attributes used for delegation.
  Why it matters: Enrollment must capture the facts that later access decisions need, even when an account could technically serve more than one relationship.

Key terms: enrollment context, relationship, authentication, access control, LOA, supplier account, organization’s account, authentication credentials, IAL1, identity proofing

3.4.4 Risk-based boundaries, attribute lifetimes, and reproofing

This section explains why account attributes can become stale and when an organization may need to reproof them.

• Changing account attributes: Distinguish attributes the system can update as they change from enrollee-provided attributes that may change without its knowledge, and contrast relatively stable traits with more changeable attributes.
  Why it matters: An account record is not necessarily current just because it was accurate at enrollment.
• Reasons for reproofing: Explain why many IAL2 and IAL3 systems require periodic reproofing and describe how document expiration or account-related events may prompt it.
  Why it matters: Reproofing helps address uncertainty about whether previously verified account information still applies.

Key terms: attributes, traits, enrollee, IAL2, IAL3, reproofing, proofed attributes, expiration date

3.4.5 The role of credentials and authentication factors

Enrollment prepares people to return to a system by providing authentication credentials, verifying or recording relevant information, and setting initial roles and defaults.

• Enrollment for later authentication: Explain how enrollment prepares enrollees to prove who they are when they return: it provides authentication credentials, often verifies important attributes such as email addresses or mobile numbers, and records digital certificates or biometrics if the system uses them.
  Why it matters: What happens at enrollment affects how a returning person can establish their identity.
• Initial roles and defaults: State that both self-service and administrative enrollment usually assign initial roles and set defaults for later use of the system.
  Why it matters: Enrollment also establishes starting settings that matter when people later use the system.

Key terms: enrollment, authentication credentials, automated proofing, digital certificates, biometrics, self-service, administrative enrollments, initial roles, defaults

3.5 Authentication factors

This section explains why remote authentication needs evidence beyond an account identifier and introduces primary and contextual authentication factors.

• Remote authentication challenge: Explain why a digital system needs a way to recognize the rightful account holder when the requester is not physically present.
  Why it matters: It explains why a login needs evidence rather than an in-person identity check.
• Identifier and factor distinction: Distinguish an identifier from an authentication factor in Alice’s login, and explain what each contributes to recognizing the account holder.
  Why it matters: Naming an account is not the same as showing that you are entitled to use it.
• Primary and contextual factors: State the primary and contextual factor categories introduced here, and distinguish the contextual factors by their lack of required additional user input.
  Why it matters: It keeps authentication from being equated with passwords alone.

Key terms: authentication, proximity problem, digital ceremony, logging in, identifier, authentication factors, primary factors, knowledge, possession, inherence

3.5.1 Primary factors

This section distinguishes knowledge, possession, and inherence authentication factors by what they rely on and the vulnerabilities each carries.

• Knowledge factor strengths and weaknesses: Explain that knowledge factors rely on something the requester knows, such as a password, PIN, or security-question answer, and why they remain common despite their weaknesses.
  Why it matters: Knowing both their convenience and vulnerabilities helps explain why a password alone offers limited assurance.
• Possession factor limits: Describe how possession factors rely on having an object and why they are stronger than knowledge factors without being immune to compromise.
  Why it matters: Having an object provides stronger evidence than knowing a secret, but it does not eliminate attack paths.
• Biometric factor tradeoffs: Explain how inherence factors use biological traits and why the section favors using them locally with other factors rather than storing biometric data remotely.
  Why it matters: Biometrics can verify a claim conveniently, but a compromised face or fingerprint cannot simply be reset.

Key terms: knowledge factors, passwords, PINs, security questions, possession factors, smartphones, hardware tokens, smart cards, security keys, inherence factors

3.5.2 Contextual factors

This subsection explains how behavior, location, and time provide contextual evidence for authentication, with examples and limitations.

• Behavioral authentication evidence: Explain how behavior factors use patterns rather than static credentials, and give an example such as mouse movements in a CAPTCHA.
  Why it matters: Behavior can provide authentication evidence without relying on a static credential.
• Location checks and limits: Describe how location factors use location signals to assess requests, including an example of their use and a limitation.
  Why it matters: A request’s apparent location is useful context, but it is not dependable proof on its own.
• Temporal authentication signals: Explain how the time of an authentication request can reveal unusual access and why it is combined with primary factors.
  Why it matters: Timing can flag suspicious activity without serving as sufficient authentication evidence by itself.

Key terms: behavior factors, inherence, CAPTCHA, location factors, geo-restrictions, velocity checks, impossible travel, temporal factors, session timing, primary factors

3.5.3 Authentication factors

This subsection distinguishes factors used for direct authentication from contextual factors typically used to assess risk.

• Primary and contextual factor roles: Distinguish how primary and contextual factors are used in authentication, including whether they are used alone or alongside other factors.
  Why it matters: The distinction helps explain how different factors contribute to telling legitimate requests from attacks.

Key terms: primary factors, contextual factors, knowledge, possession, inherence, behavior

3.6 Authentication methods

This section introduces four authentication methods, ordered by strength, and explains that each uses an identifier for the account being claimed.

• Authentication method strength ordering: State the four authentication methods in increasing order of strength and explain that each uses an identifier representing a claim to an account.
  Why it matters: This ordering gives you a framework for comparing the methods discussed next.

Key terms: identifier, identifier only, token based, identifier with authentication factors, challenge–response

3.6.1 Identifier only

The section explains how a returned identifier can maintain a web session and why that identifier must be kept secret.

• Identifier-only session flow: Trace how a service gives Alice an identifier on her first visit and how she returns it on later requests to claim the same account or session. Explain how browser cookies provide this continuity even though HTTP is stateless.
  Why it matters: It explains why a browser can stay in the same session across separate web requests.
• Identifier secrecy and impersonation: Explain why identifier-only authentication depends on an identifier that cannot easily be guessed or stolen. Describe the impersonation risk and how TLS helps protect identifiers in transit.
  Why it matters: If someone else obtains the identifier, they may be able to act as the legitimate requester.

Key terms: identifier-only authentication, browser cookies, session, stateless, HTTP, shared secret, public identifiers, impersonate, TLS, HTTP headers

3.6.2 Token based

This section explains how token-based authentication differs from identifier-only authentication and why an authenticated token is more than an arbitrary identifier.

• Authenticated token issuance: Explain how token-based authentication builds on identifier-only authentication: the token acts as an identifier but is issued after enrollment and stronger authentication for a session.
  Why it matters: The order of enrollment, authentication, and issuance explains what makes this method more secure than using an identifier alone.
• Authenticated versus ordinary cookies: Distinguish a cookie used as evidence of prior authentication from a cookie that has not been authenticated.
  Why it matters: This distinction prevents treating every browser cookie as proof that someone signed in.

Key terms: token-based authentication, identifier-only authentication, token, enrollment, web cookie, session management

3.6.3 Identifier with authentication factors

This section explains how an identifier and bound authentication factors are used to claim and verify an account, and why adding a one-time password can make a password alone insufficient for an attacker.

• Identifier and factor flow: Trace how Alice registers an identifier and authentication factors, then uses them at login: the identifier specifies the account she claims, while the factors help prove her control of it. Describe that factors may be presented together or through progressive disclosure.
  Why it matters: It separates naming an account from proving a claim to that account.
• Multifactor password protection: Explain why a password is often paired with a one-time password (OTP): the OTP acts as a possession factor and makes a stolen, guessed, or phished password less useful on its own.
  Why it matters: It explains why adding a factor can protect an account even when its password is compromised.

Key terms: identifier, authentication factors, progressive disclosure, multifactor authentication, possession factor, one-time password (OTP)

3.6.4 Challenge–response

Explains how challenge–response authentication proves control of a secret without revealing it, why unique challenges resist replay, and how public-key systems put the method into practice.

• Challenge–response and replay resistance: Explain how an identifier, challenge, and response let a requester prove control of a secret, and why a distinct challenge for each request prevents reuse of an intercepted response.
  Why it matters: A valid response should prove something about this login attempt, not be a message an attacker can use again.
• Public-key authentication flow: Trace Alice’s registration and login in the public-key example, including what the service stores, what Alice signs, and how the service checks her response.
  Why it matters: This concrete flow shows how a service can check possession of a secret it never receives.
• Challenge–response implementations: Describe passkeys as a public-key challenge–response option, including WebAuthn’s browser integration and the usability drawback noted here; name other examples of the same public-key approach.
  Why it matters: These examples connect the public-key flow to authentication options readers may encounter.
• Certificates and trusted attributes: Explain what a digital certificate packages and why trusting its issuer can let an authentication service accept verified attributes without preregistering the requester.
  Why it matters: Certificates offer a way to use trusted identity information beyond a public key registered directly with the service.

Key terms: challenge–response, identifier, replay attack, public key, private key, cryptographically sign, verify the signature, passkeys, WebAuthn, SSH key authentication

3.7 Attack models for authentication

The section points readers to a table of common authentication attacks and previews their role in the upcoming discussion of authentication strength.

3.7.1 Authentication assurance levels

This section introduces NIST authentication assurance levels as a way to compare authentication strength and describes where the classification is used.

• Authentication assurance level purpose: Explain that NIST’s authentication assurance levels (AALs), from NIST SP 800-63B, provide a common way to compare authentication strength.
  Why it matters: AALs give you a shared reference point when discussing authentication strength.
• AAL adoption and mandate distinction: Describe where AALs are commonly referenced, and distinguish healthcare vendors’ use of them from a HIPAA requirement.
  Why it matters: Common use of AALs does not mean every cited regulation requires them.

Key terms: authentication assurance levels, AALs, NIST SP 800-63B, NIST classification, HIPAA, authentication-system vendor literature

3.7.2 Authentication strength and usability

This section compares authentication methods by strength and usability, explaining their main vulnerabilities and why it recommends passkeys for everyday use.

• Lower pyramid methods and tradeoffs: Describe how passwords, one-time passwords, and app push notifications compare in security and usability, including their principal weaknesses.
  Why it matters: Comparing both attacks and user effort helps explain why adding an authentication step is not always the best improvement.
• Passkey security and usability: Explain why the section recommends passkeys and identify the device-related threats that still require attention.
  Why it matters: Passkeys are presented as a practical way to improve security and ease of use together.
• PKI assurance and adoption limits: Distinguish PKI's potential trust advantage from the usability and cost reasons the section does not recommend it for every everyday authentication problem.
  Why it matters: The strongest-looking option is not necessarily the most practical choice for routine use.
• Pyramid scope and exceptions: Explain what the pyramid compares and why identifier-only and token-based authentication do not occupy fixed levels on it.
  Why it matters: These exceptions prevent a misleading ranking based only on convenience or on the presence of a token.

Key terms: passwords, one-time passwords, push notifications, credential stuffing, phishing, SIM swapping, passkeys, phishing resistant, MFA fatigue, key store

3.8 Connecting authentication and authorization

This section explains how authentication grounds authorization decisions in the right identity and relationship context, including the current state of the requester’s device.

• Authentication as an authorization foundation: Explain why authentication must verify that the current requester is the person who enrolled, and why weak authentication undermines authorization even when permissions are correctly defined.
  Why it matters: An access decision is only as reliable as the authentication of the person requesting access.
• Authenticated relationship context: Describe how authenticating a requester gives the system access to information recorded about their relationship since enrollment, and how that context can inform access decisions.
  Why it matters: Authorization can use relationship information only if it is associated with the right requester.
• Device posture in access decisions: Explain what device posture assesses and why a successfully authenticated identity might still be denied access based on the device.
  Why it matters: Knowing who is requesting access does not by itself establish that their device is suitable for sensitive access.

Key terms: authentication, authorization, identity relationship, proximity problem, relationship context, attributes, roles, group memberships, access decisions, device posture

3.9 Relationship integrity

This section explains how authentication preserves digital relationship integrity and why authorization becomes unreliable when that integrity fails.

• Digital relationship integrity: Explain how enrollment, authentication, and other relationship processes keep a system’s understanding of a requester aligned with reality, and what can happen when they are weak.
  Why it matters: A system can act confidently on a relationship that no longer reflects who is actually making a request.
• Authentication as authorization foundation: Explain why correctly designed and enforced access policies can still produce dangerous results when authentication has established the wrong identity context, and distinguish strong authentication from good authorization.
  Why it matters: Correct access rules cannot compensate for a mistaken belief about who is making the request.

Key terms: relationship integrity, enrollment, authentication, authorization, identity context, access control policies, policy engine

3.10 Summary