Authentication and Authorization

Authentication and authorization answer different security questions.

Authentication asks, “What identity is making this request, and how much confidence do you have in that claim?”
Authorization asks, “May this identity perform this action on this resource under these conditions?”

You need both questions because a verified identity does not receive universal access. A payroll employee can be authenticated and still be forbidden from reading another department's records. A public visitor can be unauthenticated and still be authorized to read a public page.

Use one mental model throughout this course:

claim → authenticate → session or assertion → authorize → enforce → record
            ↑                                  ↑
      identity evidence                 policy and context

Authentication produces evidence about a subject. Authorization evaluates that subject against policy for a specific request. Enforcement makes the decision effective. Logging preserves enough context to explain what happened.

Start with subjects and identities

A subject is the person, workload, device, or process that requests access. An identity is the representation a system uses for that subject within a defined context.

Identity is contextual. The same person can have a workforce identity, a customer identity, and a pseudonymous account. Those records need not expose one global identity.

Do not confuse identification with proof. A username identifies the account being claimed. It does not prove that the claimant controls that account.

Identity proofing goes further. It establishes confidence that a digital identity corresponds to a claimed real-world subject. Some services need it. Others only need a stable pseudonymous account. Select the required assurance from the harm caused by an error.

Workloads also authenticate. A service may prove possession of a private key or another credential bound to its workload identity. Device identity can add useful context. Neither replaces the end-user identity when a service acts for a user.

Authentication verifies a claim

An authenticator is something a claimant controls and uses in an authentication protocol. Passwords, one-time passcode devices, and cryptographic keys are different authenticator types.

Authentication factors describe the property being demonstrated:

Factor	Meaning	Examples
Something you know	Knowledge of a secret	Password or activation secret
Something you have	Control of a physical authenticator	Security key or one-time passcode device
Something you are	A biometric characteristic	Fingerprint or face used by an authenticator

Two steps using the same factor do not create multi-factor authentication. A password followed by another memorized secret still demonstrates knowledge twice.

A successful authentication proves control of one or more authenticators bound to an account. It does not necessarily prove a legal name. It also does not prove that the same person still controls the session hours later.

Authentication strength depends on the whole exchange. Consider authenticator resistance to guessing, theft, replay, phishing, verifier compromise, and recovery abuse. Also consider how the authenticator was bound to the account and how it is replaced.

Recovery is part of authentication security. A strong login followed by weak recovery creates a weak route into the account. Treat enrollment, binding, recovery, revocation, and notification as one authenticator lifecycle.

Sessions carry authentication forward

Applications rarely repeat the complete authentication exchange for every action. They establish a session after authentication and issue a session secret to the client.

Possession of that secret associates later requests with the authentication event. A stolen session secret can therefore have an impact similar to stolen credentials.

Protect the session as carefully as the login:

generate session secrets with enough unpredictability;
transmit them only through protected channels;
keep them out of URLs and logs;
rotate them after authentication and privilege changes;
define inactivity and overall timeouts;
terminate them on logout, revocation, or material risk;
require recent authentication for sensitive actions.

Reauthentication confirms the subscriber's continued presence and intent. It is useful when the session is old, risk changes, or an action has high impact.

Federation creates separate sessions at the identity provider and relying party. Ending one does not automatically end the other. The relying party remains responsible for deciding whether its own freshness requirement has been met.

Assertions and tokens are evidence

An identity provider can authenticate a subject and send an assertion to a relying party. An authorization server can issue an access token for delegated access. A system can also use an opaque session identifier.

These artifacts have different purposes. Their format does not determine their meaning.

A JSON Web Token is a token format. It can carry many kinds of claims. It is not automatically an identity token, access token, session, or permission decision.

Validate every token according to its intended use. Typical checks include integrity, issuer, audience, lifetime, token type, and protocol-specific state. Then perform authorization. A valid token can still request a forbidden resource.

OAuth two point zero is an authorization framework for delegated access. It is not a general authentication protocol. OpenID Connect adds an interoperable identity layer for authentication. Separate planned courses cover both protocols in detail.

Authorization evaluates the request

Authorization needs more context than “is logged in.” Express the decision as a request tuple:

subject + action + resource + context → permit or deny

Subject: user, workload, device, or delegated actor
Action: read, change, approve, delete, execute, or administer
Resource: account, record, file, API operation, secret, or system
Context: ownership, tenant, time, network, device state, risk, or workflow state

Policy maps that tuple to a decision. Enforcement must occur on every path that can reach the protected effect.

Authorization fails when a system checks only one dimension. A user may read an invoice but not change it. The user may change their invoice but not another tenant's invoice. They may change ordinary fields but not an approval flag.

Write authorization requirements before selecting a framework. Start with the business rule and the harm you need to prevent. Then choose an access-control model that can express the rule.

Access-control models

Most systems combine several models.

Access control lists

An access control list attaches permissions to a resource or principal. It works well for direct grants on a bounded set of objects. It becomes hard to reason about when grants spread across many resources and groups.

Role-based access control

Role-based access control assigns permissions to roles and roles to users. Roles represent stable job functions such as payroll-reader or incident-commander.

RBAC reduces repeated per-user grants. It can also support role hierarchies and separation-of-duty constraints. Poor role design produces role explosion or broad roles that violate least privilege.

Attribute-based access control

Attribute-based access control evaluates attributes of the subject, resource, action, and environment against policy. It can express rules such as:

permit read when
subject.department equals resource.department
and resource.classification is at or below subject.clearance
and device.compliant is true

ABAC supports fine-grained context. Its cost is policy, attribute, and data-quality complexity. An outdated department or device attribute can create a wrong decision.

Relationship-based access control

Relationship-based access control follows relationships between subjects and resources. Examples include owner, editor, team-member, parent-folder, or project-member.

ReBAC fits collaborative and hierarchical resources. It requires clear rules for inheritance, graph traversal, deletion, and stale relationships.

Use roles for stable organizational responsibilities. Use attributes for contextual rules. Use relationships for ownership and sharing. Combine them when the policy requires it, but keep each decision explainable.

Design policy from least privilege

Least privilege grants only the permissions needed for the required task. Apply it to actions, resources, fields, time, and delegation.

Deny by default means unmatched requests fail closed. New routes, resources, and actions remain inaccessible until policy explicitly permits them.

Separate duties when one person should not complete a sensitive workflow alone. For example, the person who creates a payment should not also approve it. Check the separation rule at the transaction, not only when roles are assigned.

Use short-lived or just-in-time privilege for exceptional administrative work. Record who requested it, who approved it, its scope, and when it expires.

Avoid treating group membership as the final rule when resource context matters. “Member of support” may allow opening the support tool. It should not automatically allow reading every customer record.

Put decisions at the enforcement point

An authentication service can establish identity. A policy engine can evaluate centralized rules. Neither protects a resource unless a policy enforcement point blocks the forbidden operation.

Place enforcement where the protected effect occurs. That usually means the service or component that owns the resource and action.

Gateways can apply shared checks. User interfaces can hide unavailable actions. Database controls can add another boundary. These layers help, but none excuses a missing server-side check.

Preserve enough identity and delegation context across service boundaries. If service A calls service B for a user, service B may need both the workload identity and the user identity. Collapsing them into one generic service account destroys accountability and can expand access.

Centralize policy semantics where practical. Keep enforcement distributed at each protected path. Version policy and make the decision inputs observable.

Test the authorization matrix

Turn policy into a matrix before writing tests:

Subject	Action	Resource relationship	Context	Expected
Employee	Read	Own record	Active employment	Permit
Employee	Read	Peer record	Active employment	Deny
Manager	Approve	Direct report's request	Under approval limit	Permit
Manager	Approve	Own request	Any	Deny
Administrator	Change policy	Production tenant	Privilege expired	Deny

Test allowed and denied paths. Change one dimension at a time. Include missing attributes, stale groups, deleted resources, alternate endpoints, background jobs, batch operations, and direct service calls.

Test the policy engine and the enforcement integration. A correct decision that is ignored is still broken authorization.

Operate the lifecycle

Authentication and authorization change as people, workloads, resources, and risk change.

Joiner, mover, and leaver processes must add, change, and remove access. Temporary assignments need explicit expiration. Service credentials need owners and rotation. Orphaned accounts and stale sessions need removal.

Review high-risk grants and policy exceptions. Prefer evidence from actual use, resource sensitivity, and business ownership over a list of group names without context.

Log authentication successes and failures, authorization denials, privileged actions, policy changes, and session events. Include the subject, action, resource, decision, policy version, and relevant reason. Do not log passwords, session secrets, access tokens, or unnecessary personal data.

Monitoring can identify unusual activity and trigger reauthentication or session termination. It does not silently upgrade authentication assurance. Risk signals can be wrong and may have privacy effects, so assess and measure them.

Common failure modes

Authentication as authorization: treating any authenticated user as permitted.
Client-side enforcement: hiding a button while leaving the server action open.
Identifier trust: assuming a hard-to-guess object identifier grants access.
Default permit: allowing requests when no rule matches or policy data is missing.
Stale identity data: keeping former roles, groups, relationships, or sessions active.
Context loss: dropping user or delegation identity between services.
Token confusion: accepting a token for the wrong audience, issuer, or purpose.
Recovery bypass: protecting login strongly while recovery accepts weaker proof.
Unscoped administration: granting broad permanent privilege for rare tasks.
Missing negative tests: testing permitted flows without proving forbidden flows fail.

What these controls cannot promise

Authentication does not prove intent for every later action. Authorization does not make a compromised endpoint trustworthy. Multi-factor authentication does not repair excessive privilege. A centralized policy engine does not cover an unintegrated path.

Zero trust does not mean trusting nothing. It means you do not grant implicit trust from network location or asset ownership alone. You still need authenticated identities, explicit policy, enforcement, and evidence.

No access-control model removes the need to understand the business rule. RBAC, ABAC, and ReBAC are ways to express policy. They do not decide what the policy should be.

A practical learning path

Learn the identity, authenticator, session, assertion, and authorization vocabulary.
Model one application as subjects, actions, resources, and context.
Write a deny-by-default authorization matrix for that application.
Select authentication assurance from the impact of authentication errors.
Map the authenticator and session lifecycle, including recovery and revocation.
Choose RBAC, ABAC, ReBAC, or a combination from the actual policy.
Place enforcement on every path to each protected effect.
Test permitted and denied cases across identity and resource boundaries.
Connect decisions to access reviews, monitoring, response, and deprovisioning.
Continue into the focused courses on MFA, federation, OAuth, OpenID Connect, and IAM operations.