Authentication, Authorization, and Accountability

Authentication, authorization, and accountability are the three control layers that most IAM discussions compress into one vague idea of “access.” That compression causes design mistakes. Teams celebrate a successful sign-in flow even though the user should not have had permission. Or they enforce strong permissions but cannot reconstruct who performed a sensitive action because the audit trail is weak. A sound IAM architecture keeps these layers separate enough to reason about, while making them work together in one decision path.

The short version is simple:

• authentication asks whether the actor is really who or what it claims to be
• authorization asks whether that authenticated actor should be allowed to perform this action on this resource in this context
• accountability asks whether the system can later explain who acted, what happened, under which policy, and with what result

That sounds obvious until real systems add delegated access, service accounts, impersonation, shared support tooling, and token exchange between services. At that point, the boundary between the three matters a great deal.

Why It Matters

If these layers are blurred together, failure analysis becomes sloppy. A login issue gets treated as a policy issue. A privilege escalation gets mistaken for an MFA failure. An incident response team sees “admin-token-01” in logs and cannot tie the activity to a human operator, workload, or approval path. The architecture may still contain good pieces, but the control story is incomplete.

The stronger design treats access as a pipeline. The request starts with identity proof, moves into a policy decision, and ends with evidence that can survive investigation, review, or dispute.

The diagram below shows that control path.

    sequenceDiagram
	    participant P as Principal
	    participant I as Identity Service
	    participant E as Policy Engine
	    participant R as Resource
	    participant L as Audit Log
	
	    P->>I: Present credential or token
	    I-->>P: Authenticated identity and session
	    P->>E: Request action on resource
	    E->>E: Evaluate grants, attributes, context
	    alt Allowed
	        E-->>R: Allow scoped action
	        R-->>L: Record actor, action, resource, result
	    else Denied
	        E-->>L: Record denial and decision reason
	    end

What to notice:

• authentication happens before the authorization decision, but does not replace it
• authorization is specific to an action, resource, and context rather than “logged in means allowed”
• accountability records both successful and denied decisions because denials often reveal misuse, probing, or broken integrations

Authentication: Proof, Not Permission

Authentication establishes confidence in identity. For humans, that usually means passwords, passkeys, MFA, or federated sign-in. For workloads, it may mean certificates, signed workload tokens, or platform-issued ephemeral credentials. The output of authentication is not permission. It is a subject with an assurance level and a session or token that can be used in later decisions.

This is one reason the statement “the user passed MFA, so let them in” is flawed. MFA can improve confidence in identity, but it does not determine whether that identity should read payroll data, rotate production secrets, or impersonate a customer support session.

Authentication design also shapes recovery, usability, and phishing resistance. A strong authentication control that users constantly bypass, or that support teams regularly override without review, creates a fragile system. IAM has to balance assurance with real operational behavior.

Authorization: Permission With Scope and Context

Authorization answers the next question: given this authenticated principal, is this action allowed here and now? That answer usually depends on:

• the actor’s grants, roles, or attributes
• the target resource and its classification
• the action being attempted
• contextual conditions such as device trust, environment, tenant, time window, or approval state

A well-designed authorization model is explicit enough to review. It does not depend on tribal knowledge like “all engineers can use that endpoint” unless such a rule is encoded clearly and intentionally. It also does not confuse broad membership labels with fine-grained entitlement meaning. A group called admins might say very little unless the policy engine can explain which actions that group truly enables.

Accountability: Evidence, Attribution, and Explanation

Accountability is often treated as “logging later,” but in IAM it is a first-class control outcome. An access system without attribution is weaker than it looks because it cannot support investigation, recertification, or dispute resolution. This matters for both people and machines. A workload identity should still be traceable to ownership, workload instance, calling service, and policy version. A human admin session should be traceable to the individual operator, the approval or elevation path, and the exact privileged actions taken.

Good accountability usually requires:

• stable subject identifiers, not only display names
• request or session identifiers that correlate events
• resource and action detail, not only generic “accessed system”
• policy context or decision reason where practical
• enough timestamp precision and integrity to reconstruct sequence

This is why shared accounts are so damaging. They collapse accountability even if authentication technically succeeded. The same is true for broad service-account reuse across unrelated jobs. When one credential represents too many actors or purposes, the evidence stops being trustworthy.

Example: A Minimal Access Decision Pipeline

The code below is intentionally small, but it shows the three layers clearly. Authentication produces an identity context. Authorization checks policy. Accountability records the result.

 1type IdentityContext = {
 2  subjectId: string;
 3  subjectType: "human" | "workload";
 4  assuranceLevel: "low" | "high";
 5  sessionId: string;
 6};
 7
 8type AccessRequest = {
 9  action: "read" | "update" | "approve";
10  resourceId: string;
11  resourceType: "document" | "payment" | "admin-panel";
12  environment: "dev" | "prod";
13};
14
15type Decision = {
16  allow: boolean;
17  reason: string;
18  audit: Record<string, string | boolean>;
19};
20
21function decideAccess(
22  identity: IdentityContext,
23  request: AccessRequest,
24  grants: Set<string>,
25): Decision {
26  const neededGrant = `${request.resourceType}:${request.action}:${request.environment}`;
27
28  if (!grants.has(neededGrant)) {
29    return {
30      allow: false,
31      reason: "missing-explicit-grant",
32      audit: {
33        subjectId: identity.subjectId,
34        sessionId: identity.sessionId,
35        decision: "deny",
36      },
37    };
38  }
39
40  if (request.environment === "prod" && identity.assuranceLevel !== "high") {
41    return {
42      allow: false,
43      reason: "step-up-authentication-required",
44      audit: {
45        subjectId: identity.subjectId,
46        sessionId: identity.sessionId,
47        decision: "deny",
48      },
49    };
50  }
51
52  return {
53    allow: true,
54    reason: "granted",
55    audit: {
56      subjectId: identity.subjectId,
57      sessionId: identity.sessionId,
58      decision: "allow",
59    },
60  };
61}

Code Walkthrough

What the snippet teaches:

• the identity context produced by authentication is separate from the permission set
• the decision depends on explicit grants and the environment, not on login alone
• the returned audit payload is part of the decision object because evidence is not optional

Real systems are more complex than this. They may use RBAC, ABAC, policy engines, signed tokens, delegated scopes, and multiple logs. The principle still holds: authentication creates trusted identity context, authorization evaluates permission, and accountability preserves evidence of the outcome.

Common Design Mistakes

• Treating successful login as equivalent to permission. Authentication confirms identity; it does not decide business access.
• Logging only successful actions. Denied attempts can reveal broken automation, privilege probing, or attack activity.
• Using shared accounts for convenience. This destroys reliable attribution and weakens every later review.
• Treating workload identities as “internal” and therefore exempt from accountability. Overprivileged or reused service identities are common breach multipliers.

Design Review Question

A company federates all employees through SSO and enforces MFA. However, its internal admin tool runs every privileged action through a single shared backend credential, and the logs record only that backend account. Has the organization solved the authentication, authorization, and accountability problem?

No. It improved authentication for the human login step, but accountability is still weak because privileged actions cannot be tied cleanly to the initiating operator. The stronger design preserves end-user or operator identity through the admin workflow, or records an auditable mapping between the user session and the backend action so investigations can reconstruct who approved and triggered the change.

Appears on These Certification Paths

SC-900 • Security+ • AWS Security Specialty • Azure identity and access topics

Continue Learning

This lesson is foundational for later chapters on RBAC, federation, PAM, workload identity, and zero trust. If these three layers still feel blurred together, fix that now before going deeper.

Quiz Time