Foundations of Digital Identity and Access Control

Introduction

Every useful digital system must answer three questions: Who is requesting access? What evidence supports that assertion? What is the requester allowed to do? These questions underlie authentication and authorization in web applications, mobile services, operating systems, cloud platforms, databases, and enterprise networks.

A failure in any part of this chain can produce serious consequences. If a system cannot distinguish one user from another, it cannot reliably assign responsibility. If it accepts weak or stolen evidence, an attacker may impersonate a legitimate user. If authorization rules are poorly designed, an authenticated user may gain access to information or operations beyond their legitimate role.

This chapter establishes the conceptual vocabulary needed for later study of passwords, multifactor authentication, tokens, sessions, OAuth 2.0, OpenID Connect, role-based access control, policy engines, and auditing. It also emphasizes an important principle: authentication and authorization are different security decisions. Knowing who a requester is does not by itself determine what that requester may do.

Learning Objectives

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

1. Explain identities, principals, subjects, objects, credentials, claims, permissions, privileges, trust, and assurance.
2. Distinguish identification, authentication, authorization, and accountability.
3. Describe how access-control decisions relate subjects, objects, actions, and policies.
4. Analyze practical identity and access-management scenarios.
5. Recognize security, privacy, ethical, and governance risks in identity systems.
6. Apply foundational principles to the design of a small full-stack application.

1. Digital Identity as a Security Abstraction

A digital identity is a structured representation of an entity in an information system. The entity may be a person, service, device, organization, process, or automated agent. An identity commonly includes an identifier and associated attributes, such as a username, email address, department, account status, or public key.

An identity is not the same as a human being. One person may have several identities—for example, personal, employee, administrator, and student accounts. Conversely, one organizational identity may be used by a service account or a workload rather than a person. Identity design must therefore specify the scope in which an identifier is meaningful.

An identifier is a value used to refer to an identity. Examples include a username, employee number, account ID, or email address. Identification is the act of presenting or discovering such an identifier. An identifier is not secret; a username can normally be known by others. Security depends on verifying control of suitable evidence, not on hiding the identifier.

A principal is an entity recognized by a system as capable of being granted rights or held accountable. A principal can be a human user, a group, a service, a device, or a process. In many systems, a principal is represented internally by a stable account or subject identifier.

A subject is the active entity that requests access to a resource. For example, a logged-in user process, API service, or database session may be a subject. An identity describes who an entity is in a system; a subject emphasizes that the entity is currently acting.

An object is a resource to which access may be controlled. Objects include files, database rows, API endpoints, functions, messages, cloud buckets, and administrative operations. In some models, the term resource is preferred because an object may be physical, logical, or an action rather than a stored object.

The basic access relationship can be expressed as:

Here, subject is the requester, action is the attempted operation, object is the target resource, context includes relevant conditions such as time or device, and policy contains the rules. The result is commonly permit or deny. This is a conceptual model rather than a numerical formula; it does not prescribe a particular implementation.

2. Identification, Authentication, and Authorization

These terms are related but must not be conflated.

Identification

Identification is the process by which a requester claims an identity or supplies an identifier. Typing a username, sending an account ID in an API request, or selecting a certificate subject are examples. Identification answers: “Which identity are you claiming?”

Identification alone provides no sufficient proof. An attacker may claim another user’s username.

Authentication

Authentication is the process of verifying a claimed identity using evidence. It answers: “What evidence supports this identity claim?” Authentication factors are often classified as:

Multifactor authentication combines evidence from independent factor categories. Using a password and a second password is generally two pieces of knowledge, not strong multifactor authentication.

Authentication may be local, performed by the application itself, or delegated to an identity provider. It may also be continuous or adaptive, with risk signals evaluated during a session rather than only at login.

Authorization

Authorization is the decision about whether an authenticated subject may perform a particular action on a particular object under specified conditions. It answers: “What is this subject allowed to do?” Authorization can be based on identity, roles, attributes, relationships, resource ownership, or contextual conditions.

A user can be authenticated successfully but denied authorization. For example, an employee may prove control of an account yet lack permission to view payroll records.

Access control

Access control is the broader system of mechanisms and policies that regulate access. It includes authentication inputs, authorization rules, enforcement points, administrative processes, and logging. Authorization is a decision; access control includes the complete governance and technical machinery that makes the decision effective.

3. Credentials, Claims, and Evidence

A credential is evidence used to authenticate a principal. Passwords, cryptographic private keys, smart cards, one-time codes, passkeys, and biometric templates are examples. A credential should be protected according to its sensitivity and should be revocable or replaceable when compromised.

A password is usually not stored directly. A server stores a password-derived verifier created by a password-hashing function with a unique salt and suitable work factor. Password hashing is designed to make large-scale guessing expensive; it is not encryption and does not allow the original password to be recovered.

A claim is an assertion about a subject. Examples include “subject 4821 authenticated,” “email verified,” “department equals Finance,” or “account is an administrator.” Claims may be produced by an authentication service and conveyed in a token. A claim is not automatically true merely because it appears in a message: the recipient must evaluate its issuer, signature or protection, audience, validity period, and context.

A token may contain claims, but possession of a token is not identical to possession of the original credential. Token theft can nevertheless enable impersonation for the token’s validity period. Systems should therefore use short lifetimes where appropriate, secure storage, audience restrictions, revocation or rotation strategies, and transport protection.

4. Permissions, Privileges, and Policy

A permission is an allowed operation on a resource, such as read:invoice or update:profile. A privilege is an authority granted to a principal, often represented as a collection of permissions. The terms are sometimes used interchangeably, but permission is usually more specific, while privilege emphasizes granted authority.

An access-control policy specifies which subjects may perform which actions on which objects and under what conditions. Policies can be represented as access-control lists, capability assignments, role definitions, attribute rules, or relationship graphs.

The principle of least privilege states that a subject should receive only the authority necessary for its legitimate tasks, for only as long as necessary. Least privilege reduces the damage caused by mistakes, compromised accounts, malicious insiders, and vulnerable software.

The separation of duties principle distributes sensitive tasks among multiple people or roles. For example, one employee may prepare a payment while another approves it. Separation of duties reduces the possibility that one compromised or dishonest account can complete an entire high-risk process.

The default-deny principle means that access is denied unless a valid rule explicitly permits it. This is generally safer than permitting access unless a rule explicitly denies it, especially in systems that evolve over time.

5. Trust and Assurance

Trust is a reliance relationship: one party accepts that another party, system, or assertion is sufficiently dependable for a specified purpose. Trust is contextual. A university may trust an identity provider to assert student enrollment, while a payment service may require additional verification before authorizing a transfer.

Assurance is the justified level of confidence in an identity, credential, authentication event, or authorization decision. Assurance depends on factors such as identity-proofing quality, credential strength, authentication method, device security, issuer reliability, and monitoring.

Trust should not be treated as unlimited or binary. A service should ask:

• Who issued the credential or claim?
• How was the identity established?
• How strong and independent were the authentication factors?
• Was the claim intended for this service?
• Is it current, unexpired, and unrevoked?
• What risks arise if the claim is wrong?

A low-risk application may accept an email verification claim, while a financial or healthcare system may require stronger identity proofing, phishing-resistant authentication, transaction confirmation, and detailed monitoring.

6. Accountability and Non-Repudiation

Accountability is the ability to associate actions with responsible identities and to investigate those actions. It depends on unique accounts, reliable authentication, authorization records, timestamps, event integrity, and suitable monitoring. Shared accounts weaken accountability because a log entry cannot reliably identify the individual who acted.

An audit record commonly includes the subject, action, object, outcome, timestamp, source device or network information, and correlation identifier. Logs should avoid unnecessary sensitive data, be protected against unauthorized alteration, and be retained according to legal and operational requirements.

Non-repudiation is a stronger and more specific property: evidence is available to support the claim that a party performed an action and cannot reasonably deny it. Digital signatures can contribute to non-repudiation, but a signature alone does not prove that a human knowingly controlled the signing key. Key protection, identity binding, operational procedures, and applicable law also matter.

Accountability is therefore broader than logging and more realistic than assuming every event can be proved with absolute certainty.

7. Major Access-Control Models

Discretionary access control

In discretionary access control (DAC), resource owners can grant or revoke access. File permissions and sharing settings are common examples. DAC is flexible but can allow permissions to spread through careless sharing.

Mandatory access control

In mandatory access control (MAC), access is governed by centrally defined labels and rules. Subjects and objects may carry classifications such as restricted or confidential. Users cannot freely override the policy. MAC is useful where information-flow restrictions are critical.

Role-based access control

In role-based access control (RBAC), permissions are assigned to roles, and users or service identities receive roles. A SupportAgent role might permit viewing support tickets but not changing billing records. RBAC simplifies administration, though large systems may experience role explosion when many exceptions are added.

Attribute-based access control

In attribute-based access control (ABAC), decisions use attributes of the subject, object, action, and environment. An example rule might permit a clinician to read a patient record when the clinician is assigned to that patient, the purpose is treatment, and the request occurs through an approved device. ABAC is expressive but requires trustworthy, current attributes and understandable policy management.

Relationship-based control

Relationship-based systems make decisions using relationships such as “user is a member of project” or “doctor is assigned to patient.” These models are particularly useful in collaborative applications and social or organizational graphs.

Real systems often combine these approaches. A policy might require a role, a resource relationship, and a contextual condition simultaneously.

8. The Access-Control Decision Path

A typical full-stack request passes through several stages:

1. The client presents an identifier or credential.
2. An authentication component verifies the credential or receives a trusted assertion.
3. The system creates a session or validates a token.
4. The request reaches an enforcement point, such as middleware or an API gateway.
5. The system evaluates subject, action, object, context, and policy.
6. The application performs the operation only if permitted.
7. The system records an appropriate audit event.

Authentication should not be implemented only in the user interface. A hidden button may improve usability, but it is not an authorization control. The server, database, or service responsible for the resource must enforce the rule.

A secure implementation should also prevent insecure direct object references. For example, changing /orders/1001 to /orders/1002 must not reveal another customer’s order merely because the requester is authenticated. The authorization check must verify ownership, role, or another valid relationship for the specific object.

9. Worked Example: A University Learning Platform

Consider a learning platform with students, instructors, and administrators. A student, Maya, signs in using a password and a passkey.

Identification: Maya submits the account identifier maya42.

Authentication: The platform verifies the password-derived verifier and the passkey assertion. It establishes a session for Maya’s principal.

Claims: The identity service provides claims that the account is active, the email is verified, and the user is enrolled in course CS301.

Authorization: Maya requests to download an assignment. The policy evaluates:

• Subject: Maya’s account
• Action: download
• Object: CS301 assignment file
• Context: current date and course enrollment
• Policy: enrolled students may download published assignments

The request is permitted. Maya then attempts to view instructor grading notes. Authentication still succeeds, but authorization denies the request because the object is restricted to instructors.

The platform logs both outcomes, while avoiding the storage of passwords or unnecessary personal data. If Maya’s enrollment is withdrawn, the authorization decision should change even if her session remains valid; this illustrates why authorization should not rely solely on an old login result.

The example demonstrates that identity, authentication, claims, and authorization are separate stages. It also shows that access decisions may depend on resource-specific relationships rather than only on a global role.

10. Ethical, Legal, and Governance Considerations

Identity systems concentrate sensitive information and power. Poor design can enable surveillance, discrimination, exclusion, or unauthorized profiling. Developers should collect only attributes necessary for a stated purpose, restrict internal access, define retention periods, and provide correction or recovery processes.

Biometric data requires particular care. Unlike a password, a fingerprint cannot simply be replaced if exposed. Biometric matching can also produce unequal error rates across populations. Biometrics should generally be treated as an authentication factor or local unlocking mechanism, not as an infallible identity.

Authorization decisions may encode organizational or social bias. An automated rule that denies access based on a flawed attribute can scale unfairness rapidly. High-impact decisions require review, explainability appropriate to the context, appeal mechanisms, and careful testing.

Organizations must also address account recovery. Recovery is effectively an alternate authentication path; a system with strong login security but weak “forgot password” procedures remains vulnerable. Recovery channels should be protected, monitored, and designed to minimize social-engineering risk.

11. Contemporary Developments and Best Practices

Passkeys and WebAuthn use public-key cryptography and can provide phishing-resistant authentication. The private key remains under the user’s control, while the service stores or recognizes a public key. This approach reduces dependence on reusable passwords, although recovery and device migration still require careful design.

Zero-trust architectures express the principle that network location alone should not establish trust. Each request should be evaluated using identity, device posture, resource sensitivity, and context. Zero trust is not a single product; it is an architectural and governance approach.

Practical best practices include:

• Use unique identities rather than shared accounts.
• Prefer phishing-resistant multifactor authentication for sensitive access.
• Store password verifiers using a modern, slow password-hashing scheme with unique salts.
• Apply authorization on the server and at the resource boundary.
• Follow least privilege, default deny, and separation of duties.
• Validate token issuer, audience, signature, expiry, and intended use.
• Protect sessions against theft and fixation; rotate or invalidate them when risk requires.
• Log security-relevant events without exposing secrets.
• Review permissions periodically and remove obsolete access.
• Test both permitted and forbidden paths, including object-level access.
• Design recovery, accessibility, privacy, and incident response from the beginning.

Challenges and Limitations

No authentication method is perfect. Passwords are reusable and vulnerable to phishing; biometrics raise privacy and recovery concerns; hardware keys can be lost; and tokens can be stolen. Strong authentication also cannot correct an authorization policy that grants excessive access.

Policy complexity is another challenge. As organizations grow, exceptions accumulate and rules become difficult to understand. Automated policy testing, clear ownership, change review, and monitoring can reduce this risk. Finally, identity systems depend on accurate lifecycle management. Hiring, transfer, suspension, and departure events must update accounts and permissions promptly.

Chapter Summary

Digital identity represents an entity within a system, while a principal is an entity that can receive authority and be held accountable. A subject actively requests access, and an object is the resource being protected. Identification presents an identity claim; authentication verifies evidence supporting that claim; authorization determines whether the authenticated subject may perform a specific action on a specific object. Access control includes the policies, mechanisms, enforcement points, and governance surrounding those decisions.

Credentials provide authentication evidence, while claims communicate assertions that must be evaluated for issuer, audience, validity, and context. Permissions describe allowed operations, privileges describe granted authority, and least privilege limits that authority. Trust and assurance are contextual rather than absolute. Accountability connects actions to responsible identities through sound identity management, enforcement, and protected audit records.

DAC, MAC, RBAC, ABAC, and relationship-based models offer different ways to organize access decisions. Modern full-stack systems commonly combine them. Secure design requires server-side enforcement, object-level checks, careful token and session handling, privacy protection, lifecycle management, and ethically governed policies.

Key Terms

Identity: A representation of an entity in an information system.

Identifier: A value used to refer to an identity.

Principal: An entity recognized as capable of receiving authority and being accountable.

Subject: An active entity requesting access.

Object: A resource or operation protected by access control.

Identification: Presentation or discovery of a claimed identity.

Authentication: Verification of evidence supporting an identity claim.

Authorization: A decision about whether an action is permitted.

Access control: Policies and mechanisms that regulate access to resources.

Credential: Evidence used to authenticate a principal.

Claim: An assertion about a subject or authentication event.

Permission: An allowed operation on a resource.

Privilege: Authority granted to a principal, often as a set of permissions.

Trust: Contextual reliance on an entity, system, or assertion.

Assurance: Justified confidence in an identity or security decision.

Accountability: Ability to associate actions with responsible identities.

Least privilege: Granting only the authority necessary for a legitimate task.

RBAC: Access control based on roles assigned to principals.

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

Default deny: Denying access unless an applicable rule explicitly permits it.

Review Questions

Short Answer Questions

1. What is the difference between identification and authentication?
2. Define a principal and give two examples.
3. Why is authentication not sufficient to authorize every request?
4. What is a claim, and why must its issuer be evaluated?
5. State the principle of least privilege.

Long Answer Questions

1. Explain the relationship among identity, principal, subject, object, credential, and claim.
2. Compare RBAC and ABAC, including one strength and one limitation of each.
3. Describe how a full-stack application should process and enforce an authenticated API request.
4. Explain how trust and assurance affect authentication requirements in low-risk and high-risk systems.
5. Discuss how logging contributes to accountability and identify its limitations.

Analytical / Application Questions

1. A student can log in successfully but can view another student’s assignment by changing an ID in the URL. Identify the access-control failure and propose a correction.
2. Design an access policy for a hospital record system using roles, relationships, and context. Explain how your policy applies least privilege and separation of duties.
3. An organization uses shared administrator accounts for convenience. Analyze the security and governance consequences and recommend a migration plan.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes identification from authentication?

A. Identification grants permissions, while authentication removes them.

B. Identification claims an identity, while authentication verifies evidence for that claim.

C. Identification encrypts data, while authentication compresses it.

D. Identification applies only to devices, while authentication applies only to people.

Correct Answer: B. Identification claims an identity, while authentication verifies evidence for that claim.

Question 2

In an access-control decision, which item is the resource being accessed?

A. Subject

B. Credential

C. Object

D. Claim

Correct Answer: C. Object

Question 3

Which is an example of a possession factor?

A. Password

B. Fingerprint

C. Hardware security key

D. Security question answer

Correct Answer: C. Hardware security key

Question 4

What does authorization determine?

A. Whether a claimed identity has been verified

B. Whether a subject may perform an action on an object

C. Whether a password is stored in plaintext

D. Whether a username is unique globally

Correct Answer: B. Whether a subject may perform an action on an object

Question 5

Which principle means access is denied unless a rule explicitly permits it?

A. Default deny

B. Complete mediation bypass

C. Open delegation

D. Shared accountability

Correct Answer: A. Default deny

Question 6

A user is authenticated but cannot view payroll records because of their role. What does this demonstrate?

A. Authentication and authorization are distinct

B. Identification is unnecessary

C. Credentials are always public

D. Logging replaces authorization

Correct Answer: A. Authentication and authorization are distinct

Question 7

Which model assigns permissions to roles and then assigns users to those roles?

A. RBAC

B. DAC only

C. Biometric control

D. Network-address control

Correct Answer: A. RBAC

Question 8

Why is changing an object ID in a URL a significant security test?

A. It tests whether the interface uses a modern font.

B. It tests whether object-level authorization is enforced.

C. It tests whether passwords are hashed.

D. It tests whether a token has a color attribute.

Correct Answer: B. It tests whether object-level authorization is enforced.

Question 9

Which practice most directly supports accountability?

A. Using shared administrator accounts

B. Disabling all security logs

C. Using unique identities and protected audit records

D. Granting every user administrator privileges

Correct Answer: C. Using unique identities and protected audit records

Question 10

Which statement about claims is correct?

A. Every claim is true once it appears in a token.

B. Claims should be evaluated for issuer, audience, validity, and context.

C. Claims are always passwords.

D. Claims eliminate the need for authorization.

Correct Answer: B. Claims should be evaluated for issuer, audience, validity, and context.