Identity & Access Management interview questions

No. The three authentication factor categories are something you know (password/PIN), something you have (token/phone), and something you are (biometrics). A fingerprint or face scan is 'something you are', a measured physical trait. The gotcha: biometrics aren't secrets and can't be rotated — if your fingerprint template leaks, you cannot change your fingerprint. That's why biometrics work best as one factor, often unlocking a local key, rather than as a standalone password replacement.

No. Deleting the cookie just removes the credential from your browser — the session record (or a still-valid JWT) on the server typically remains usable until it expires or is explicitly invalidated. An attacker who already captured the token can keep using it. The misconception treats the cookie as the session itself; it is only a pointer to server-side state. Real logout must invalidate the session server-side, or revoke and short-TTL the token.

No. MFA raises the bar a lot, but OTP and push factors are phishable: adversary-in-the-middle kits (e.g. Evilginx) proxy the login and relay the code in real time, and MFA-fatigue/push-bombing tricks users into approving. Captured codes are reusable within their short window. The misconception is 'MFA = unphishable'; the factor type is what matters. Phishing-resistant MFA — FIDO2/WebAuthn passkeys bound to the site's origin — is what actually defeats this.

Not by itself. Many systems keep existing sessions and previously issued tokens valid after a password change — OAuth refresh tokens, 'app passwords', API keys, and persistent cookies — so an attacker with a live session can stay in. The correct response is to change the password AND invalidate all sessions and tokens, revoke app credentials, and audit MFA devices and recovery settings. Assuming a password reset alone evicts the attacker is a classic incident-response mistake.

No. A salt is a unique, random value stored right alongside the hash; its job is to make identical passwords hash differently and to defeat precomputed rainbow tables — not to stay secret. It's fine if an attacker who steals the database also gets the salts. What actually protects passwords is a slow, salted hash (bcrypt, scrypt, Argon2). A separate, optional secret 'pepper' is a different concept.

Unbounded autonomy plus tool access is OWASP LLM 'excessive agency': a manipulated or mistaken model can take destructive actions. Constrain it with least-privilege tool scopes, require human confirmation for irreversible operations, and keep permissions narrow and audited. Trusting it or granting admin widens the blast radius, and hiding a UI button does nothing about the model's underlying capability to call the action.

If retrieval pulls any indexed document regardless of who's asking, the model will faithfully surface data the user shouldn't see — this is an authorization flaw, not hallucination. Enforce the user's document-level permissions at retrieval time so only authorized chunks enter the context. A bigger system prompt is bypassable and doesn't implement access control, temperature is unrelated, and another model has the same gap.

Password storage needs a deliberately slow, salted, memory-hard hash — bcrypt, scrypt, or Argon2 — so cracking stolen hashes is expensive and rainbow tables don't apply. A fast hash like SHA-256 is trivially brute-forced at scale; reversible encryption means one key compromise exposes every password at once; and plaintext is indefensible no matter how locked down the database is. Choose Argon2id (or bcrypt) with a tuned work factor and a unique per-user salt.

Auditors test for evidence, not intent: show the access-review policy, dated records of each review with approver sign-off, and confirmation that flagged access was revoked and verified. A verbal confirmation proves nothing repeatable, a promise to start next quarter shows the control was not operating in the audit period, and an org chart describes reporting lines, not access decisions. Only the dated, attributable artifacts demonstrate the control operated as designed across the whole period.

Leaver risk is lingering access, so the control to verify is timely deprovisioning of every access path — directory accounts, SSO, VPN, privileged and service credentials, and third-party SaaS — reconciled against the joiner/mover/leaver (JML) process. Assuming HR handles it all without verification leaves gaps no one owns. Keeping the account active 'in case they come back' is standing, unmonitored risk. Disabling only email ignores the many other systems the person could still reach. The point is to verify access is actually and fully removed, not to trust that it was.

Urgency, authority, and skipping verification are textbook social-engineering pressure aimed at a high-value account. The agent must follow the defined identity-verification process before resetting anything, and escalate if it can't be satisfied. Resetting on demand, using a guessable 'security question' like a favorite color, or emailing the new password to the caller all hand an attacker control of the executive's account.

Unused, over-privileged service accounts are prime targets and a large attack surface. Inventory them, disable or delete the unused ones (watching for breakage), right-size the survivors to least privilege, and give each an owner plus a recurring review. Leaving them is standing risk, granting blanket admin maximizes blast radius, and consolidating onto one shared account destroys least privilege and accountability.

An open redirect on an auth flow lets an attacker craft a trusted-looking login link that, after authentication, sends the user — and potentially an auth code or token — to an attacker-controlled domain, enabling account takeover and convincing phishing. Fix it by strictly allow-listing exact redirect URIs server-side and rejecting anything else. It is not cosmetic and not a performance issue, and HTTPS doesn't help because the attacker's destination can be a valid HTTPS site too.

LSASS stores cached credentials and secrets, so an unexpected process reading its memory is a hallmark of credential theft (e.g., mimikatz-style dumping). Triage the offending process and parent, isolate the host to stop lateral movement, and rotate the credentials that could have been captured — including privileged and service accounts. It has nothing to do with graphics rendering or disk space, and ignoring it as normal can lead to domain-wide compromise. The benign-sounding distractors are exactly how analysts miss an active intrusion.

This is broken access control (IDOR): the server isn't checking that the authenticated user may access the requested object. The fix is per-object authorization enforced server-side on every request. Sanitizing the number doesn't establish ownership. Encrypting or obfuscating the ID is obscurity that's still guessable, leakable, or replayable. The HTTP method is irrelevant to authorization. Always verify the caller's right to the specific object before returning it.

Balance usability and risk: enforce conditional access tied to device posture and isolate corporate data in a managed container (MAM/MDM) so it can be controlled and selectively wiped without taking over a personal device. Unrestricted access risks leakage on unmanaged, possibly compromised endpoints. An outright ban pushes people to insecure workarounds like forwarding data to personal email. And emailing attachments scatters sensitive data uncontrollably across devices you can never reclaim.

Network-location trust means a single foothold inside grants broad lateral access — one phished VPN credential and the attacker is 'inside.' Zero trust removes implicit trust: every access is authenticated, authorized, and continuously evaluated on identity and device posture, with least privilege and segmentation (NIST SP 800-207). A second VPN or a wider VPN just extends the same flat-trust problem to more places, and trusting the LAN instead of the VPN repeats the original mistake.

Secrets belong in a managed store with access control, audit, and rotation, injected at runtime — never committed to source control. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault) and remove the committed values from history, then rotate them because they must be treated as compromised. Base64 is encoding, not protection — anyone can decode it. A private repo still spreads the secret to everyone with clone access plus CI systems and forks. Compiling it into the binary just hides a secret that's still trivially extractable.

A static key baked into an image leaks easily and lives forever, so the fix is to eliminate the long-lived credential entirely: attach an IAM role via an instance profile, which delivers short-lived, automatically rotated credentials with nothing embedded. Manual 90-day rotation still leaves a long-lived secret sitting in the AMI between rotations. Moving the key to an environment variable doesn't make it any less static or any less leaked. Emailing it to ops spreads the exposure to mailboxes and archives.

An over-privileged instance role turns any application-level flaw — notably an SSRF that reaches the instance metadata service — into full-account takeover, because the attacker inherits the role's credentials. Replace the wildcard with the minimal actions and resource ARNs the workload actually uses, and require IMDSv2 to harden the metadata endpoint. A VPC doesn't constrain IAM at all. A single deny rule is whack-a-mole that leaves everything else permitted. A load balancer is irrelevant to the credential's blast radius.

The point is impact: a reused or over-privileged service credential that unlocks domain admin or critical systems is the finding that matters, so test for reuse and map the privilege and lateral-movement path. Cracking every other hash first is busywork that delays the real story. Changing the service-account password is destructive, breaks production, and tips off defenders. Emailing a live credential in plaintext is itself an exposure and bad operational security.

Executives are exactly the accounts attackers want (BEC, wire fraud), so exempting them inverts the risk model. Solve the friction, not the control: deploy phishing-resistant FIDO2/passkeys that are faster than codes. Caving to the exemption guts the program's credibility and leaves your highest-value accounts unprotected. Killing the MFA project abandons a top-tier control. Quietly enabling it behind their backs destroys trust and accountability.

Least privilege plus just-in-time access: grant the minimum permissions needed, time-boxed and logged, so debugging is possible without standing admin that becomes a permanent risk and audit gap. Permanent cluster-admin violates least privilege and widens the blast radius of any compromise. A blanket denial blocks legitimate work and invites risky shadow workarounds. Sharing the common admin service-account credential destroys accountability — actions can't be traced to a person.

Treat any pushed secret as burned: revoke and rotate it first, because bots scrape public commits within seconds, then review CloudTrail for misuse and purge it from history. Deleting the commit doesn't help — the key is already cloned, forked, and cached by third parties. Making the repo private leaves a live, already-leaked key in attackers' hands. Adding the file to .gitignore does nothing for a secret that is already committed.

Validate before escalating. Corporate VPNs, cloud proxies (like CASB or M365 service IPs) and mobile carriers routinely produce false 'impossible travel,' so check the egress IPs, the MFA result, and the device/user-agent before pulling the trigger. Auto-locking on every hit causes alert fatigue and erodes user trust in the SOC. Assuming it's always a false positive misses real account takeover. Emailing the manager is slow and isn't a security control — the logs answer the question faster and more reliably.

Assume the password is already compromised: force a reset AND invalidate the account's active sessions and tokens, because a reset alone won't evict an attacker who already holds a live session or refresh token. Then hunt for anomalous logins, MFA prompts, mailbox rules and OAuth grants from the exposure window. Deleting the email or telling the user to change it "next time" leaves the account wide open. An antivirus scan addresses malware on the endpoint, not stolen credentials in the cloud.

Credential stuffing replays known username:password pairs from third-party breaches, betting on password reuse — high success rate per attempt, often distributed across many IPs and devices to look human. Password spraying tries one or two common passwords (like Winter2026!) across many accounts to stay under lockout thresholds. Stuffing exploits reuse; spraying exploits weak shared passwords. MFA defeats both.

On Windows, local account hashes (NTLM) live in the SAM hive under C:\Windows\System32\config\SAM, protected while the OS runs; live credentials sit in LSASS memory, and domain hashes are in NTDS.dit on a domain controller. On Linux, hashes are in /etc/shadow (readable only by root), while /etc/passwd holds account metadata. Attackers steal these to crack passwords offline or pass-the-hash.

SPF publishes which IPs may send mail for a domain. DKIM adds a cryptographic signature so the receiver can verify the message was not altered and came from the domain. DMARC ties SPF/DKIM results to the visible From: header via 'alignment', tells receivers what to do on failure (none/quarantine/reject), and sends reports. SPF and DKIM alone do not protect the From a user sees — DMARC is what enforces that.

DAC lets the data owner grant access at their discretion; MAC enforces access centrally via labels/clearances and is non-discretionary; RBAC grants access through job roles; ABAC evaluates attributes (user, resource, environment) against policy for fine-grained, context-aware decisions.

Classification labels data by sensitivity so the organization applies controls proportional to value and risk, avoiding both under-protection and wasteful over-protection. The data owner (a business role) sets the classification and accepts risk, while the data custodian (often IT) implements and maintains the protective controls.

Due diligence is the ongoing investigation and understanding of risks (knowing what should be done), while due care is taking the reasonable actions a prudent person would take to address them (actually doing it). Diligence is research and oversight; care is implementation and maintenance.

Identity lifecycle management governs an account from creation to retirement: provisioning at onboarding (joiner), adjusting entitlements on role change (mover), and timely deprovisioning at exit (leaver), with periodic access reviews throughout. The most common failures are privilege creep on movers and orphaned accounts from missed deprovisioning.

A policy is the high-level mandatory statement of management intent; a standard is a mandatory specific rule that enforces policy (e.g. AES-256); a procedure is the mandatory step-by-step how-to; a guideline is an optional recommendation. Policies, standards, and procedures are mandatory, while guidelines are discretionary.

Quantitative analysis assigns hard monetary values so you can compute expected loss; qualitative analysis ranks risk on relative scales (high/medium/low) using expert judgment. Quantitative uses SLE = asset value x exposure factor, ARO = expected occurrences per year, and ALE = SLE x ARO to express annual expected loss in dollars.

You can mitigate (reduce likelihood/impact with controls), transfer (shift the financial impact via insurance or contracts), avoid (stop the risky activity entirely), or accept (knowingly tolerate the residual risk). The choice depends on risk appetite and a cost-benefit comparison against the risk's expected loss.

A user is a long-lived identity with permanent credentials; a role is an identity with no permanent credentials that any trusted principal can assume to get short-lived tokens; a policy is the JSON document that grants permissions, attached to either. Least privilege means preferring roles over users, scoping policies to specific actions and resources, and granting only what a task needs — then reviewing and pruning over time.

IMDS is a link-local endpoint (169.254.169.254) that gives an instance its metadata, including temporary credentials for its attached IAM role. SSRF can trick the server into fetching that URL and leaking those credentials. IMDSv2 requires a PUT to obtain a short-lived session token, sets a default IP TTL/hop limit of 1, and rejects requests with certain headers — so a simple SSRF GET can no longer reach it.

The classic mistakes are public ACLs or bucket policies that allow anonymous or all-AWS-users access, overly broad principals or wildcard actions, no default encryption, and no logging. Prevent them by enabling account-level Block Public Access, using IAM/bucket policies with least privilege, enforcing default encryption and TLS, and turning on access logging and Config rules to catch drift.

Store secrets in a dedicated managed service (Secrets Manager, Parameter Store, Vault), encrypted with a KMS key, and grant access through IAM roles so workloads fetch them at runtime with short-lived credentials. Never bake secrets into code, container images, or committed .env files. Add automatic rotation, scoped key policies, and audit logging so every retrieval is traceable.

The provider secures the cloud itself — physical data centers, hardware, the hypervisor, and the managed services they run. You secure what you put in the cloud — your data, identities, configurations, OS patching where applicable, and access controls. The exact line shifts: with IaaS you own the OS up, with SaaS you mostly own data and access.

CI/CD is high-value because it holds deploy credentials and runs untrusted code. Risks include compromised dependencies and build actions, leaked or over-broad secrets, mutable third-party actions, and over-privileged runners or OIDC trust. Reduce them with pinned and verified dependencies, short-lived OIDC federation instead of long-lived keys, least-privilege scoped to specific repos/branches, isolated ephemeral runners, and signed, provenance-tracked artifacts (SLSA).

A JWT is three base64url parts — header, payload (claims), and signature — joined by dots. The server signs the header and payload with a secret or private key, and verifies that signature on each request to trust the claims without server-side session state. Pitfalls: accepting alg=none, RS256-to-HS256 key confusion, not validating expiry/issuer/audience, putting secrets in the readable payload, and no revocation path.

Kerberos relies on a trusted Key Distribution Center (KDC). The client authenticates once to the Authentication Server and gets a Ticket-Granting Ticket (TGT) encrypted with the KDC's key. To reach a service, it presents the TGT to the Ticket-Granting Service and receives a service ticket encrypted with that service's key. The service decrypts and trusts it. Passwords never traverse the network, and tickets are time-limited.

The app redirects the user to the authorization server to log in and consent. The server redirects back with a short-lived authorization code. The app's backend then exchanges that code (plus its client secret) at the token endpoint for an access token, over a server-to-server back channel. This keeps tokens out of the browser/URL. Public clients add PKCE to bind the code to the original requester.

Store passwords using a deliberately slow, salted, adaptive password-hashing function — bcrypt, scrypt, or Argon2 — never a fast general-purpose hash like SHA-256 or MD5. Fast hashes are built for speed, so attackers with GPUs can test billions of guesses per second against a leaked database. Slow hashes have a tunable work factor (and memory cost) that makes each guess expensive, keeping brute force impractical even after a breach.

The client builds a chain from the server (leaf) certificate up through one or more intermediate CAs to a root CA in its trust store. It verifies each certificate's signature using the next issuer's public key, checks validity dates, name/hostname match, key usage, and revocation (CRL/OCSP). Trust terminates at a self-signed root that is pre-trusted; the chain is valid only if every link checks out.

A salt is a unique, random value generated per user and combined with the password before hashing. It ensures identical passwords produce different hashes and makes precomputed attacks like rainbow tables useless, since the attacker would need a separate table per salt. Salts are stored alongside the hash. A pepper is an additional secret value, the same for all users, kept separately (e.g., in app config or an HSM) so a database leak alone isn't enough.

SSO centralizes authentication at an Identity Provider (IdP). When a user visits a Service Provider (the app), the app redirects to the IdP; the user logs in once, and the IdP returns a signed assertion or token vouching for their identity. SAML carries this as a signed XML assertion; OIDC carries it as a signed JSON ID token layered on OAuth 2.0. The app trusts the IdP's signature rather than handling passwords itself.

TOTP (Time-based One-Time Password) combines a shared secret, established at enrollment, with the current time divided into fixed windows (usually 30 seconds). It runs HMAC over the time-step counter with the secret, then truncates the result to a 6-digit code. Both the app and server hold the same secret and clock, so they independently compute the same code — no network call needed. The code rotates each window.

The CIA triad is the three core goals of information security: confidentiality (only authorized parties can read data), integrity (data isn't altered without authorization), and availability (authorized users can access systems when needed). Almost every control maps to one or more of these.

Defense in depth means layering multiple independent security controls so that if one fails, others still protect the asset. It assumes no single control is perfect — for example combining a firewall, network segmentation, endpoint protection, MFA, least privilege, and encryption rather than relying on a perimeter alone.

Least privilege means every user, process, and service gets only the minimum access required for its task, and nothing more. It limits the blast radius of a compromised account, reduces insider-threat risk, and shrinks the attack surface. You apply it via role-based access, regular access reviews, and just-in-time elevation.

MFA requires two or more authentication factors from different categories — something you know (password), something you have (phone/token), something you are (biometric). It helps because an attacker who steals one factor, like a password, still can't log in without the others. Phishing-resistant MFA like FIDO2 is strongest.

Phishing is social engineering that tricks people into revealing credentials, sending money, or running malware, usually via fake emails or sites. Defense is layered: email filtering and authentication (SPF/DKIM/DMARC), MFA to limit stolen-credential damage, user awareness training, and an easy way to report suspicious messages.

UEBA (User and Entity Behaviour Analytics) builds behavioural baselines for users and entities (hosts, service accounts, devices) and uses statistics or machine learning to score deviations as risk. It excels at threats that have no clean signature: compromised credentials, insider misuse, and lateral movement — e.g. a user suddenly accessing systems they never touch, at unusual hours, or moving abnormal data volumes. It complements rule-based detection rather than replacing it, and needs tuning to avoid false positives from legitimate behaviour change.

Access reviews (recertification) are periodic checks where an accountable owner confirms each person's access is still justified, and revokes what isn't. They're the backstop that catches privilege creep, orphaned accounts, and entitlements granted for a project that ended. The control only works if a knowledgeable owner — usually the manager or resource owner — actually scrutinizes access rather than rubber-stamping it, and if revocations are enforced.

Conditional access makes the access decision depend on context rather than a fixed rule. It evaluates signals — who the user is, device compliance, location, the app, and a computed risk score from anomaly detection — and responds proportionally: allow, block, or require step-up like MFA or a compliant device. Risk-based access is the dynamic variant where a real-time risk signal drives the policy.

Identity federation establishes trust between an identity provider (IdP) that authenticates users and service providers (relying parties) that consume that authentication. The IdP verifies the user and issues a signed assertion or token; the service provider trusts it instead of managing its own credentials. This enables cross-domain SSO and centralized control, but concentrates risk: compromise the IdP and you compromise everything that trusts it.

Just-in-time access grants elevated privileges only when needed, for a limited time, usually with approval — then they expire automatically, so there's no standing privilege to steal. Break-glass accounts are the deliberate exception: highly privileged emergency accounts, normally dormant, locked behind strict controls and heavy alerting, used only when normal access paths fail. JIT shrinks the everyday attack surface; break-glass guarantees you can still get in during a crisis.

Modern NIST SP 800-63B favors length over complexity: allow long passphrases (at least 8, support 64+), accept all characters including spaces, and don't impose composition rules like 'one uppercase, one symbol.' Screen new passwords against known-breached lists, drop mandatory periodic expiration (rotate only on evidence of compromise), and ditch knowledge-based 'security questions.' The aim is rules that resist real attacks instead of just annoying users into predictable patterns.

Phishing-resistant MFA means the second factor can't be replayed against the real site even if the user is tricked. FIDO2/WebAuthn passkeys achieve this with origin-bound public-key cryptography: the authenticator signs a challenge tied to the real site's domain, so a credential captured by a lookalike or attacker-in-the-middle site is useless. TOTP codes and push prompts are still phishable because they can be relayed in real time.

PAM controls and monitors the accounts that can do the most damage — domain admins, root, service accounts. It vaults and rotates their credentials so secrets aren't shared or hardcoded, brokers sessions so admins never see the raw password, records what privileged users do, and ideally grants elevation just-in-time rather than standing access. The goal is to shrink the blast radius of the accounts attackers most want.

RBAC grants permissions through roles assigned to users — simple to reason about but prone to role explosion as edge cases multiply. ABAC evaluates policies over attributes of the user, resource, action, and environment, so it scales to fine-grained, context-aware decisions at the cost of complexity. Most mature systems layer them: roles for coarse grants, attributes and policy for the conditional details.

SCIM (System for Cross-domain Identity Management) is a standard REST/JSON API and schema for creating, updating, and deleting user accounts across applications. Wired to an HR system or IdP, it automates the joiner-mover-leaver lifecycle: accounts and entitlements are provisioned on hire, adjusted on role change, and — most importantly — deprovisioned on departure, eliminating the orphaned accounts attackers love.

Keep access tokens short-lived (minutes) so a stolen one expires fast, and use longer-lived refresh tokens to get new access tokens without re-prompting the user. Rotate refresh tokens on every use and detect reuse of a consumed token as a theft signal, revoking the chain. The goal is to balance limiting the window of a compromised token against not forcing users to re-authenticate constantly.

Zero Trust drops the assumption that being inside the network makes you trusted. Every request to a resource is authenticated and authorized on its own merits — verifying identity, device health, and context — by a policy decision point, granting least-privilege access per session. There is no trusted internal zone; the network location of a request is just one signal, not a free pass.

A risk assessment identifies assets and their value, the threats and vulnerabilities that could affect them, then estimates risk as a function of likelihood and impact. You can do it qualitatively (high/medium/low, fast and subjective) or quantitatively (SLE × ARO = ALE, data-driven but harder). Frameworks like NIST RMF and ISO 27005 give it structure, and the output feeds risk treatment: mitigate, transfer, avoid, or accept.

Enumerate the account's privileges and the host's misconfigurations: token privileges like SeImpersonate, unquoted service paths, weak service permissions, AlwaysInstallElevated, and stored credentials. Then abuse the most reliable one — token impersonation (Potato attacks) is a common route to SYSTEM.

Defense in depth means layering multiple independent security controls so that if one fails, others still protect the asset. No single control is assumed perfect, so you stack preventive, detective, and responsive measures across the network, host, application, and data layers.

Least privilege means every user, process, or service gets only the minimum access required to do its job, and nothing more. It shrinks the blast radius of any compromise or mistake. You enforce it with role-based access, just-in-time elevation, regular access reviews, and removing standing admin rights.

Never hardcode secrets in source or commit them to git. Store them in a dedicated secrets manager or vault, inject them at runtime, scope access with least privilege, rotate regularly, and prefer short-lived dynamic credentials over long-lived static ones. Audit every access.

Enforce TLS everywhere, authenticate every request (e.g. OAuth2/OIDC tokens), and authorize per-object so users can only reach their own data. Add input validation, rate limiting and quotas, schema validation, and thorough logging. The most common API flaw is broken object-level authorization, so check ownership on every resource access.

Segmentation divides a network into isolated zones so a breach in one can't freely reach others, limiting lateral movement. Zero trust goes further: it removes implicit trust based on network location entirely, authenticating and authorizing every request regardless of where it originates — microsegmentation is one way to implement it.

Brute force targets a single account with many password guesses, so you see many failures concentrated on one username. Password spray flips it: one or a few common passwords tried across many accounts, low and slow, so each account sees only a couple of failures. The detection signal is the ratio of accounts to failures and the timing, not raw failure counts.

Lateral movement is an attacker using a foothold to reach other systems. Signs include unexpected network logons (type 3) and RDP (type 10), access to admin shares like C$ and ADMIN$, remote-execution tools such as PsExec, WMI, and WinRM, pass-the-hash patterns, and a normally local account suddenly authenticating to many hosts.

Confirm the alert is real before acting: read what fired and why, then enrich it — who is the user, is the source IP/geo/device expected, is this impossible travel, were there prior failures? Classify true vs false positive, escalate or contain if real (disable session, force MFA reset), and document everything so the next analyst can follow your reasoning.

HTTP is stateless — each request is independent and carries no memory of prior ones. Sessions add state on top: after login, the server issues an identifier the browser stores in a cookie and replays on every request. Server-side sessions keep the state on the server keyed by an opaque session ID; stateless tokens like JWTs put signed state in the token itself so the server can verify without storage.