Question 1

Compare JWT Token Authentication versus Stateful Sessions, and explain OAuth 2.0 PKCE flow.

Accepted Answer

### 1. Stateful Sessions vs Stateless JWTs:
- **Stateful Sessions**: Stored in server memory or Redis with a session ID sent via 'httpOnly' cookie. Easy to revoke instantly on the server, but requires a shared session store across microservices.
- **Stateless JWTs**: Self-contained signed tokens containing claims. Great for decoupled microservices, but invalidating them before natural expiration requires token blacklists or short TTLs.

### Storage Security Trade-Offs:
Storing tokens in 'localStorage' makes them accessible to client-side JavaScript, leaving them vulnerable to **Cross-Site Scripting (XSS)**. The gold standard pattern is storing access tokens in memory and long-lived refresh tokens in 'httpOnly, Secure, SameSite=Strict' cookies.

### OAuth 2.0 PKCE Flow:
**Proof Key for Code Exchange (PKCE)** replaces client secrets for public clients (SPAs, mobile apps). It generates a dynamic cryptographically random code verifier and code challenge per authorization attempt, preventing authorization code interception attacks.

Key Takeaway: Store refresh tokens in httpOnly SameSite=Strict cookies to protect against XSS and CSRF attacks.

Question 2

What is the fundamental difference between Authentication (AuthN) and Authorization (AuthZ)?

Accepted Answer

While often conflated, Authentication and Authorization solve two separate identity challenges in secure software systems:

### 1. Authentication (AuthN) — "Who are you?":
- Verifies and proves the identity of a user, service, or device.
- Occurs **first** in the security request lifecycle.
- **Examples**: Entering a password, scanning a fingerprint (Biometrics), verifying a 2FA TOTP code, or logging in via OAuth SSO.
- **Protocols**: OpenID Connect (OIDC), SAML 2.0, WebAuthn/Passkeys.

### 2. Authorization (AuthZ) — "What are you allowed to do?":
- Determines permissions and access rights granted to an authenticated principal.
- Occurs **second** (after successful identity verification).
- **Examples**: Checking if a user can delete a database row, view a financial report, or access an admin URL route.
- **Protocols**: OAuth 2.0, Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC).

Key Takeaway: Authentication verifies identity (Who you are); Authorization verifies permissions (What you can access).

Question 3

Why should passwords never be stored in plain text and how do bcrypt and Argon2id work?

Accepted Answer

Passwords must **never** be stored in plain text or encrypted with reversible symmetric algorithms. If a database is breached, cleartext or reversible passwords compromise every user account.

### Key Concepts:
1. **One-Way Cryptographic Hashes**: Mathematical functions that convert cleartext passwords into fixed-length strings that cannot be reversed.
2. **Salting**: Appending a unique, random string (salt) to each password before hashing. Prevents pre-computed **Rainbow Table** attacks and ensures identical passwords produce completely different hash outputs.
3. **Slow Key Derivation Functions (KDFs)**:
   - Fast hash functions (MD5, SHA-256) process billions of hashes per second on GPUs, making brute-force trivial.
   - Slow algorithms like **Argon2id** (winner of Password Hashing Competition) and **bcrypt** enforce configurable memory and CPU work factors, rendering GPU brute-force attacks computationally infeasible.

Key Takeaway: Hash passwords using slow, salted key derivation algorithms like Argon2id or bcrypt to block GPU brute-force attacks.

Question 4

How does traditional Cookie-Based Stateful Session Authentication work?

Accepted Answer

Cookie-Based Stateful Session Authentication is the classic web application security pattern:

### Execution Flow:
1. **Credentials Submission**: Client sends username/password via POST to '/api/login'.
2. **Server Session Creation**: Upon credential verification, the server creates a unique, cryptographically random **Session ID** (e.g. 128-bit UUID/entropy) and stores user context in server RAM or Redis store.
3. **Set-Cookie Header**: Server responds with a 'Set-Cookie: session_id=abc123xyz; HttpOnly; Secure; SameSite=Lax' response header.
4. **Automatic Request Inclusion**: The browser automatically includes the 'session_id' cookie in every subsequent HTTP request to that domain.
5. **Validation**: Server looks up 'session_id' in Redis to retrieve user permissions.

Key Takeaway: Stateful sessions store user context on the server (Redis) referenced by an opaque HTTP-only session cookie.

Question 5

What are the 3 parts of a JSON Web Token (JWT) and how is the signature validated?

Accepted Answer

A **JSON Web Token (JWT)** (RFC 7519) is an open standard for securely transmitting claims between parties as a compact, self-contained JSON object.

### The 3 Dot-Separated Components:
$$	ext{JWT} = 	ext{Header} + "." + 	ext{Payload} + "." + 	ext{Signature}$$

1. **Header**: Contains token type ('"JWT"') and signing algorithm (e.g. '"HS256"' or '"RS256"'). Base64Url encoded.
2. **Payload**: Contains claims (statements about the subject like 'sub', 'name', 'roles', 'exp'). Base64Url encoded.
3. **Signature**: Created by taking the Base64Url-encoded header and payload, and signing it using a secret or private key:
   $$	ext{Signature} = 	ext{HMACSHA256}(	ext{Base64}(H) + "." + 	ext{Base64}(P), 	ext{secret})$$

### Crucial Warning:
Base64Url encoding is **NOT encryption**! Anyone can decode and read JWT payload claims. The signature guarantees **integrity**, not confidentiality.

Key Takeaway: JWTs contain 3 Base64Url parts (Header, Payload, Signature); signatures verify token integrity but do not encrypt payload data.

Question 6

What is the difference between Access Tokens and Refresh Tokens?

Accepted Answer

Modern authentication architectures use paired tokens to balance security and user experience:

### 1. Access Tokens:
- **Purpose**: Authorizes immediate access to protected API endpoints.
- **Lifetime**: Short-lived (5 to 15 minutes).
- **Format**: Usually stateless signed JWTs containing user scopes and permissions.
- **Storage**: Kept in memory (JavaScript variable or React state) to prevent persistent storage attacks.

### 2. Refresh Tokens:
- **Purpose**: Exchanged at the auth server to obtain new access tokens without forcing the user to re-enter passwords.
- **Lifetime**: Long-lived (7 to 30 days).
- **Format**: Opaque random strings backed by a database session record.
- **Storage**: Stored securely in 'httpOnly, Secure, SameSite=Strict' cookies.

Key Takeaway: Short-lived access tokens authorize API requests; long-lived refresh tokens securely renew access tokens without re-login.

Question 7

What are the 4 core roles in the OAuth 2.0 Framework (RFC 6749)?

Accepted Answer

The **OAuth 2.0 Authorization Framework** (RFC 6749) defines 4 primary roles to enable third-party applications to obtain limited access to an HTTP service:

### 1. Resource Owner (User):
The end user who owns the account data and grants access to their resources (e.g. your Google account owner).

### 2. Client (Application):
The third-party application requesting access to the resource owner's account (e.g. a Mobile App or Web App).

### 3. Authorization Server (Identity Provider):
The server that authenticates the Resource Owner, requests consent, and issues access tokens upon success (e.g. 'accounts.google.com').

### 4. Resource Server (API Gateway):
The API server hosting protected user resources that accepts and validates OAuth 2.0 access tokens (e.g. 'google.googleapis.com/drive/v3').

Key Takeaway: OAuth 2.0 divides responsibilities across 4 roles: Resource Owner (User), Client (App), Auth Server (IdP), and Resource Server (API).

Question 8

What is Single Sign-On (SSO) and what are its core architectural benefits?

Accepted Answer

**Single Sign-On (SSO)** is an authentication scheme that allows a user to log in once with a single set of credentials (e.g. username/password + MFA) and automatically gain access to multiple independent applications and systems.

### How SSO Works:
1. Applications delegate authentication to a central **Identity Provider (IdP)** (e.g. Okta, Auth0, Keycloak, Entra ID).
2. When accessing a Service Provider (SP), the user is redirected to the central IdP.
3. If already authenticated at the IdP, the IdP issues a signed identity assertion (OIDC ID Token or SAML Response) back to the SP without asking for credentials again!

### Key Benefits:
- **User Experience**: Eliminates password fatigue and repeated logins.
- **Security**: Centralizes password policies, MFA enforcement, and instant single-click account revocation upon employee off-boarding.

Key Takeaway: SSO centralizes user authentication at an Identity Provider, eliminating password fatigue and streamlining account revocation.

Question 9

What is Role-Based Access Control (RBAC) and how do Roles and Permissions map?

Accepted Answer

**Role-Based Access Control (RBAC)** is an authorization model where access permissions are assigned to specific **Roles**, and **Users** are assigned one or more Roles.

### Key Components:
- **Permissions**: Fine-grained atomic actions (e.g. 'posts:create', 'users:delete', 'reports:view').
- **Roles**: Logical groupings of permissions matching job functions (e.g. 'Admin', 'Editor', 'Viewer').
- **User-Role Mapping**: Assigning roles to individual user accounts.

### Advantages:
Decouples authorization logic from individual user IDs. Adding a new employee requires simply assigning a role rather than managing dozens of individual permissions.

Key Takeaway: RBAC maps atomic permissions to roles, and roles to users, simplifying administrative authorization control.

Question 10

How does Two-Factor Authentication (2FA) using TOTP (Time-based One-Time Passwords) work?

Accepted Answer

**Multi-Factor Authentication (MFA)** requires users to present two or more distinct authentication factors:
1. **Knowledge Factor**: Something you know (Password, PIN).
2. **Possession Factor**: Something you have (Authenticator App, Hardware Token, Phone).
3. **Inherence Factor**: Something you are (Fingerprint, FaceID).

### How TOTP (Time-Based One-Time Password - RFC 6238) Works:
1. **Setup**: Server generates a cryptographically random **Secret Seed Key** displayed to the user as a QR Code ('otpauth://totp/...').
2. **Sync**: User scans the QR code into an Authenticator App (Google Authenticator, 1Password).
3. **Calculation**: Both client app and server calculate matching 6-digit codes every 30 seconds using HMAC-SHA1 over the current Unix timestamp:
   $$	ext{TOTP} = 	ext{Truncate}(	ext{HMAC-SHA1}(	ext{Secret}, \lfloor 	ext{CurrentTimestamp} / 30 floor))$$

Key Takeaway: TOTP 2FA computes matching 6-digit codes every 30 seconds using a shared secret key and current Unix timestamp.

Question 11

How do SameSite Cookie attributes (Strict, Lax, None) defend against CSRF attacks?

Accepted Answer

**Cross-Site Request Forgery (CSRF)** occurs when a malicious website causes a user's web browser to perform an unwanted action on a trusted site where the user is currently authenticated (by exploiting automatic cookie transmission).

### SameSite Cookie Attribute Defense:
The 'SameSite' attribute controls whether cookies are sent with cross-site requests:

1. **'SameSite=Strict'**: The cookie is **NEVER** sent in cross-site requests (even when clicking a link from an external site). Maximum security.
2. **'SameSite=Lax'** (Modern Browser Default): The cookie is withheld on cross-site sub-requests (e.g. images, AJAX POSTs), but sent when a user follows a top-level link ('<a>' href GET navigation).
3. **'SameSite=None'**: The cookie is sent on all cross-site requests. **Must** be accompanied by the 'Secure' flag (HTTPS only).

Key Takeaway: SameSite=Strict/Lax prevents browsers from attaching session cookies to cross-site malicious AJAX POST requests, mitigating CSRF.

Question 12

Compare HTTP Basic Authentication versus Bearer Token Authentication.

Accepted Answer

Both Basic and Bearer authentication transmit credentials inside the standard HTTP 'Authorization' request header, but use different formats: ### 1. HTTP Basic Authentication ('Authorization: Basic '): - Transmits Base64-encoded 'username:password' string (e.g. 'Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ='). - **Stateless & Simple**, but sends raw user credentials on every single API request. - Requires HTTPS to prevent credential sniffing. Cannot enforce fine-grained scope permissions easily. ### 2. HTTP Bearer Token Authentication ('Authorization: Bearer '): - Transmits an opaque or signed security token (e.g. JWT or OAuth access token). - The caller ("bearer") presenting the token is granted access without disclosing raw user passwords. - Supports token expiration, scopes, and instant server-side revocation. Key Takeaway: Basic Auth sends Base64-encoded username:password on every request; Bearer Auth sends security tokens (JWT) instead of passwords.

Question 13

What is OpenID Connect (OIDC) and how does it extend OAuth 2.0 for Identity?

Accepted Answer

OAuth 2.0 is strictly an **Authorization Framework** (delegating access rights). Using raw OAuth 2.0 for user authentication creates security flaws (pseudo-authentication). **OpenID Connect (OIDC)** is an identity layer built directly on top of OAuth 2.0.

### What OIDC Adds to OAuth 2.0:
1. **ID Token (JWT)**: A cryptographically signed token containing standardized identity claims ('sub', 'name', 'email', 'iss', 'aud').
2. **Standardized Scopes**: Defines 'openid', 'profile', 'email', 'address', 'phone'.
3. **'/userinfo' Endpoint**: Standardized API endpoint to fetch user profile attributes using the access token.
4. **Discovery Document**: '/.well-known/openid-configuration' metadata endpoint listing IdP URLs and public keys.

Key Takeaway: OIDC extends OAuth 2.0 by adding signed ID Tokens and standardized identity endpoints for user authentication.

Question 14

What are Passkeys (WebAuthn / FIDO2) and how do they eliminate passwords?

Accepted Answer

**Passkeys** (built on W3C WebAuthn and FIDO2 standards) are a modern replacement for passwords that use public-key cryptography.

### How Passkeys Eliminate Passwords:
1. **Key Pair Generation**: During registration, the user's local device (TouchID, FaceID, YubiKey, Windows Hello) generates a unique public/private key pair bound specifically to that domain.
2. **Public Key Storage**: The server stores **ONLY the public key**.
3. **Private Key Isolation**: The private key **never leaves the user's hardware secure enclave**.
4. **Challenge Authentication**: During login, the server sends a random challenge nonce. The device signs the challenge using its private key after verifying local biometrics.

### Primary Advantage:
100% immune to **Phishing Attacks** because authenticators refuse to sign challenges for mismatched domain origins!

Key Takeaway: Passkeys replace passwords with public-key cryptography bound to hardware biometrics, providing total immunity to phishing.

Question 15

What is Attribute-Based Access Control (ABAC) and how does it compare to RBAC?

Accepted Answer

While RBAC grants access based strictly on static user roles (e.g. 'Admin'), **Attribute-Based Access Control (ABAC)** evaluates dynamic boolean policy rules based on 4 attribute categories:

### The 4 ABAC Attribute Categories:
1. **Subject Attributes**: User properties (department, clearance level, age, tenure).
2. **Resource Attributes**: Target data properties (classification level, document owner, project status).
3. **Action Attributes**: Requested operation (read, edit, delete, export).
4. **Environment Attributes**: Contextual signals (current time, client IP address, network threat level).

### Example ABAC Policy:
*"Allow access if 'Subject.department == Resource.department' AND 'Resource.isConfidential == false' AND 'Environment.time < 17:00'"*.

Key Takeaway: ABAC evaluates dynamic boolean rules across Subject, Resource, Action, and Environment context attributes.

Question 16

Why must Access-Control-Allow-Credentials: true be configured carefully with CORS?

Accepted Answer

**CORS (Cross-Origin Resource Sharing)** is a browser security mechanism that restricts cross-origin HTTP requests initiated from scripts.

### The Credentials Security Boundary:
When an application makes cross-origin requests requiring cookies, HTTP authentication, or TLS client certificates, the client sets 'credentials: 'include''.

### Key Security Rules:
1. When 'Access-Control-Allow-Credentials: true' is set on the server, **the server CANNOT specify a wildcard origin ('Access-Control-Allow-Origin: *')**.
2. Browsers will reject credentialed responses if the origin is set to '*'.
3. The server must dynamically validate incoming 'Origin' headers against an explicit whitelist of trusted domains and mirror back the validated origin!

Key Takeaway: When enabling Access-Control-Allow-Credentials, servers must explicitly mirror allowed origins instead of using wildcard *.

Question 17

How does Passwordless Email Magic Link authentication work?

Accepted Answer

**Passwordless Magic Links** allow users to log in without passwords by clicking a single-use secure link sent to their verified email address.

### Execution Flow:
1. User enters email at '/login'.
2. Server generates a high-entropy random token (e.g. 256-bit crypto string) or a signed JWT.
3. Server stores a **SHA-256 hash of the token** in the database with a short expiration TTL (5 to 10 minutes) and 'used: false' flag.
4. Server emails the unhashed token link ('https://app.com/verify?token=...').
5. User clicks the link. Server hashes the incoming query token, verifies match and expiration, marks token as used, and issues a session cookie.

Key Takeaway: Magic links store token hashes in DB with short TTLs, emailing unhashed single-use links for passwordless login.

Question 18

What are API Keys and when are they appropriate for service-to-service authentication?

Accepted Answer

**API Keys** are unique secret strings (e.g. 'sk_live_9921...') assigned to software projects or developer accounts to identify and authenticate incoming API requests.

### Storage Best Practices:
1. **Never Store Plaintext API Keys**: Just like passwords, store only **SHA-256 hashes of API keys** in the database.
2. **Prefixing**: Include a identifiable prefix (e.g. 'sk_live_' or 'pk_test_') to allow automated secret scanning tools (GitHub Secret Scanning) to detect leaked keys in public code repositories.

### When to Use:
Ideal for developer API access, CLI tools, and simple machine-to-machine integrations. Use OAuth 2.0 when acting on behalf of delegate end-users.

Key Takeaway: Prefix API keys for secret scanner detection and store only SHA-256 key hashes in database tables.

Question 19

What is a Session Fixation attack and how do you prevent it during login?

Accepted Answer

**Session Fixation** is an attack vector where an attacker tricks a victim into authenticating using a **known session ID pre-set by the attacker**.

### Attack Scenario:
1. Attacker visits an application, obtains an anonymous session ID ('SID_999'), and sends a link containing 'SID_999' to the victim.
2. Victim logs into the application using the link.
3. If the application keeps 'SID_999' after authentication, the attacker now shares an authenticated session with the victim!

### Mitigation:
**Session Regeneration**: Always destroy the anonymous session and issue a brand-new, cryptographically random Session ID immediately upon successful login!

Key Takeaway: Always regenerate the session ID immediately upon user authentication to prevent session fixation attacks.

Question 20

Why are the exp (Expiration Time), iat (Issued At), and nbf (Not Before) claims critical in JWTs?

Accepted Answer

Standard JWT specifications (RFC 7519) define registered metadata claims to manage token lifetimes:

### Key Registered Claims:
1. **'exp' (Expiration Time)**: Unix timestamp (in seconds) after which the token **MUST NOT** be accepted. Limits the damage window of leaked stateless tokens.
2. **'iat' (Issued At Time)**: Unix timestamp identifying when the token was created. Used to invalidate tokens issued prior to password resets.
3. **'nbf' (Not Before Time)**: Unix timestamp identifying the earliest time the token can be processed.

### Clock Skew Tolerance:
Servers processing JWTs across distributed systems allow a small clock skew (e.g. 5 to 60 seconds) to account for minor server time drift.

Key Takeaway: The exp claim enforces token lifetimes, limiting the vulnerability window of leaked stateless JWTs.

Question 21

How do you implement Logout for Stateful Sessions versus Stateless JWTs?

Accepted Answer

Handling user logout differs significantly depending on the underlying session architecture:

### 1. Stateful Sessions:
- **Server Action**: Delete the session record from Redis or server RAM immediately.
- **Client Action**: Clear the session cookie via 'Set-Cookie' with an expired date.
- **Result**: Instant, 100% reliable revocation across all endpoints.

### 2. Stateless JWTs:
- **Client Action**: Clear tokens from local memory/cookies.
- **Server Challenge**: Because JWTs are stateless, a leaked token remains valid until its natural 'exp' time!
- **Server Revocation Solution**: Store the token's unique identifier ('jti') in a Redis **Revocation Blacklist** until the token's natural expiration time passes.

Key Takeaway: Stateful logout deletes server session records; stateless JWT logout requires adding the token jti to a Redis blacklist.

Question 22

How do Cross-Domain SSO redirects exchange authentication tokens safely?

Accepted Answer

Browser security boundaries prevent scripts on one domain ('app-a.com') from reading cookies on another domain ('sso-idp.com'). Cross-Domain SSO resolves this via **Authorization Code Exchange Redirects**.

### Step-by-Step Flow:
1. **Front-Channel Redirect**: 'app-a.com' redirects browser to 'sso-idp.com/auth?response_type=code&state=xyz123'.
2. **IdP Verification**: User authenticates at 'sso-idp.com'.
3. **Auth Code Callback**: IdP redirects browser back to 'app-a.com/callback?code=AUTH_CODE_99&state=xyz123'.
4. **Back-Channel Token Exchange**: 'app-a.com' backend makes a direct server-to-server POST request to 'sso-idp.com/token' exchanging 'AUTH_CODE_99' for access/ID tokens.
5. **'state' Parameter**: Prevents CSRF by verifying that the returned 'state' matches the value stored in the client session before redirect.

Key Takeaway: Cross-domain SSO exchanges temporary authorization codes via back-channel server requests, protecting tokens from browser inspection.

Question 23

What is HMAC Request Signing and how does it prevent API payload tampering?

Accepted Answer

**HMAC (Hash-based Message Authentication Code) Request Signing** is a security technique used by high-security APIs (such as AWS Signature V4, Stripe Webhooks, or financial gateways) to verify both **identity** and **payload integrity**.

### How HMAC Request Signing Works:
1. **Canonicalization**: Client constructs a canonical string combining HTTP Method, Path, Timestamp, Nonce, and Request Body.
2. **Signature Computation**: Client computes HMAC-SHA256 signature using a shared secret key:
   $$	ext{Signature} = 	ext{HMAC-SHA256}(	ext{CanonicalString}, 	ext{SecretKey})$$
3. **Header Transmission**: Client sends signature and timestamp in HTTP headers ('X-Signature', 'X-Timestamp').
4. **Server Verification**: Server re-computes the HMAC signature using the stored secret key and asserts exact match + timestamp freshness (< 5 mins).

Key Takeaway: HMAC request signing verifies request body integrity and identity using a shared secret key without sending raw secrets over the wire.

Question 24

What is SAML 2.0 (Security Assertion Markup Language) and where is it used?

Accepted Answer

**SAML 2.0 (Security Assertion Markup Language)** is an XML-based open standard for exchanging authentication and authorization assertions between an enterprise Identity Provider (IdP) and a Service Provider (SP).

### Key Features:
- **Format**: Uses XML payloads signed with X.509 digital certificates.
- **Widespread Enterprise Adoption**: Standard protocol for enterprise IdPs like Okta, Ping Identity, and Microsoft Active Directory / Azure AD.
- **SAML Assertions**: Transmits XML statements containing user identity ('NameID'), attributes (email, group memberships), and session validity rules.

Key Takeaway: SAML 2.0 is an XML-based enterprise SSO standard using X.509 signed assertions to exchange identity between IdPs and SPs.

Question 25

How does the Double Submit Cookie pattern defend against CSRF attacks?

Accepted Answer

When SameSite cookies cannot be used (e.g. legacy browsers or cross-domain POST requests), applications use **CSRF Tokens**. The **Double Submit Cookie Pattern** provides stateless CSRF protection without server session state.

### How Double Submit Cookie Works:
1. When generating a response, the server sets a random, high-entropy CSRF token in a non-httpOnly cookie ('csrf_token=random_string').
2. When submitting a POST request, client JavaScript reads 'csrf_token' from the cookie and attaches it in a custom HTTP header ('X-CSRF-Token: random_string').
3. The server compares the cookie value against the custom header value.
4. **Security Principle**: Malicious cross-site scripts on external domains can cause browsers to send cookies automatically, but SOP (Same-Origin Policy) prevents them from reading the cookie value to populate the custom header!

Key Takeaway: Double Submit Cookie pattern verifies that a custom HTTP header matches a cookie value, blocking cross-site CSRF submissions.

Question 26

Why are Account Lockout and Login Endpoint Rate Limiting necessary?

Accepted Answer

Public authentication endpoints ('/login') are prime targets for automated attacks:
- **Brute-Force Attacks**: Systematically guessing passwords for a specific username.
- **Credential Stuffing**: Testing millions of leaked username/password pairs obtained from dark web breaches.

### Defensive Controls:
1. **IP Rate Limiting**: Caps maximum login attempts per IP address (e.g. max 5 attempts per minute) using Redis sliding window algorithms.
2. **Account Lockout**: Temporarily locks an individual user account (or triggers CAPTCHA) after 5 consecutive failed attempts.
3. **Exponential Backoff**: Dynamically increases delay times between consecutive failed attempts ($1s, 2s, 4s, 8s...$).

Key Takeaway: Protect login endpoints against brute-force and credential stuffing using IP rate limiting and account lockouts.

Question 27

What are OAuth 2.0 Scopes and how do they restrict API access boundaries?

Accepted Answer

**OAuth 2.0 Scopes** (RFC 6749) specify the exact degree of access and permissions that a user authorizes a third-party application to perform on their behalf.

### Key Concepts:
- **Scope Format**: Space-delimited list of case-sensitive strings (e.g. 'scope="read:user write:orders delete:items"').
- **Consent Screen**: During OAuth authorization, the Auth Server displays requested scopes to the user for explicit approval.
- **Granted Scopes**: The Auth Server may grant a subset of requested scopes.
- **Principle of Least Privilege**: Access tokens issued with restricted scopes prevent a compromised third-party app from abusing full account access.

Key Takeaway: OAuth 2.0 scopes define fine-grained permission boundaries granted to third-party applications.

Question 28

How does Social Login (Sign in with Google/GitHub) work via OAuth 2.0 and OIDC?

Accepted Answer

**Social Login** allows users to authenticate to a web application using their existing accounts from major Identity Providers (Google, GitHub, Apple, Facebook).

### Execution Flow:
1. User clicks "Sign in with Google".
2. Web app redirects user to Google's OAuth 2.0 authorization URL with requested scopes ('openid email profile').
3. User authenticates at Google and grants permission.
4. Google redirects back to web app callback URI with an authorization code.
5. Web app backend exchanges authorization code for Google ID Token and Access Token.
6. Web app extracts verified user email from ID Token and links/creates local user session.

Key Takeaway: Social login leverages OAuth 2.0/OIDC to delegate authentication to trusted providers like Google or GitHub.

Question 29

Why are Security Questions considered insecure compared to TOTP or Hardware Security Keys?

Accepted Answer

Legacy Knowledge-Based Authentication (KBA) (e.g. *"What is your mother's maiden name?"* or *"What was your first pet's name?"*) is widely considered insecure by NIST security standards.

### Vulnerabilities of Security Questions:
1. **Public OSINT Exposure**: Answers are frequently discoverable via public social media profiles (LinkedIn, Facebook, ancestry sites).
2. **Low Entropy & Predictability**: Common answers (e.g. *"Fluffy"* or *"Smith"*) can be easily dictionary-attacked.
3. **Phishing & Social Engineering**: Attackers can trick users or support staff into answering KBA questions.

### Modern Superior Alternatives:
TOTP Authenticator Apps (Google Authenticator) and Hardware Keys (Passkeys/FIDO2) rely on **dynamic cryptographic keys**, rendering social engineering ineffective.

Key Takeaway: Security questions are insecure due to public OSINT exposure; replace KBA with dynamic TOTP or hardware Passkeys.

Question 30

What does the HttpOnly cookie flag do and why does it prevent XSS token theft?

Accepted Answer

The **'HttpOnly'** attribute is a security flag added to the 'Set-Cookie' HTTP response header that instructs the web browser that the cookie **MUST NOT be exposed to client-side scripts**.

### Why HttpOnly Prevents XSS Token Theft:
- If a token is stored in 'localStorage', 'sessionStorage', or a non-HttpOnly cookie, any successful **Cross-Site Scripting (XSS)** vulnerability allows an attacker's injected JavaScript snippet to execute:
  'const stolenToken = document.cookie;' or 'localStorage.getItem('token')' and transmit it to an attacker's server!
- When a cookie is marked 'HttpOnly', browser APIs ('document.cookie') return an empty string for that cookie, completely blocking malicious XSS scripts from reading the session token!

Key Takeaway: HttpOnly blocks client-side JavaScript (document.cookie) from accessing cookies, protecting session tokens from XSS theft.

Question 31

How do you implement OAuth 2.0 PKCE (Proof Key for Code Exchange) step-by-step?

Accepted Answer

**Proof Key for Code Exchange (PKCE)** (RFC 7636) is mandatory for OAuth 2.0 public clients (Single Page Apps, Mobile Apps) that cannot securely hide a client secret.

### Step-by-Step PKCE Implementation:
1. **Generate Code Verifier**: Client creates a high-entropy random string (43 to 128 chars from '[A-Z, a-z, 0-9, -, ., _, ~]').
2. **Compute Code Challenge**: Client calculates SHA-256 hash of 'code_verifier' and Base64URL-encodes the result:
   $$	ext{code\_challenge} = 	ext{Base64URL}(	ext{SHA256}(	ext{code\_verifier}))$$
3. **Authorization Request**: Client redirects browser to Auth Server including 'code_challenge' and 'code_challenge_method=S256'.
4. **Token Exchange**: When exchanging the authorization code, client sends the unhashed 'code_verifier'.
5. **Server Verification**: Auth Server hashes the received 'code_verifier' and verifies it matches the original 'code_challenge'.

Key Takeaway: PKCE generates a dynamic verifier and SHA-256 challenge per authorization attempt, securing public clients without secrets.

Question 32

What is the difference between Symmetric (HS256) and Asymmetric (RS256/ES256) JWT signing?

Accepted Answer

Selecting JWT signing algorithms impacts key management across distributed microservices:

### 1. Symmetric Signing (HS256 - HMAC with SHA-256):
- Uses a **single shared secret key** for both signing and verifying tokens.
- **Drawback**: Every microservice that needs to verify JWTs must hold the secret key. If a downstream microservice is compromised, an attacker can forge valid tokens for the entire ecosystem!

### 2. Asymmetric Signing (RS256 / ES256 - RSA/ECDSA):
- Uses a **Private/Public Key Pair**.
- **Auth Server** holds the Private Key to sign JWTs.
- **Microservices** hold ONLY the Public Key (fetched via JWKS) to verify JWT signatures.
- **Advantage**: Downstream services can verify tokens without having the power to forge tokens!

Key Takeaway: RS256 uses private keys to sign and public keys to verify, allowing microservices to validate JWTs without holding signing secrets.

Question 33

How do JWKS (JSON Web Key Sets) endpoints enable zero-downtime key rotation?

Accepted Answer

**JSON Web Key Set (JWKS)** (RFC 7517) is a standard endpoint ('/.well-known/jwks.json') exposed by Identity Providers that publishes public keys used to verify signed JWTs.

### Zero-Downtime Key Rotation Architecture:
1. **Key ID ('kid') Header**: Every JWT header includes a 'kid' specifying which key signed the token.
2. **JWKS Key Array**: The JWKS endpoint returns an array of active public keys:
   '{ "keys": [ { "kty": "RSA", "kid": "key-2026-01", ... }, { "kty": "RSA", "kid": "key-2026-02", ... } ] }'
3. **Dynamic Fetching & Caching**: Microservices fetch and cache public keys locally. When a JWT arrives with a new 'kid', the service refreshes its JWKS cache and matches the public key seamlessly!

Key Takeaway: JWKS endpoints publish active public keys matched by token kid headers, enabling zero-downtime key rotation across microservices.

Question 34

What is Open Policy Agent (OPA) and how does it decouple authorization policy from application code?

Accepted Answer

Embedding complex 'if/else' permission logic directly inside application code leads to policy fragmentation and auditing challenges. **Open Policy Agent (OPA)** decouples authorization policy from application logic.

### How OPA Works:
1. **Rego Language**: Policies are written in **Rego**, a declarative policy language.
2. **Policy Sidecar Execution**: OPA runs as a lightweight sidecar container alongside applications.
3. **Query/Decision Loop**: The application queries OPA over HTTP/gRPC passing JSON context ('{ user, action, resource }'). OPA evaluates policies and returns a structured boolean decision ('{ "allow": true }').

Key Takeaway: Open Policy Agent (OPA) evaluates Rego policies in sidecar microservices, decoupling authorization logic from application code.

Question 35

What is Relationship-Based Access Control (ReBAC) and the Google Zanzibar model?

Accepted Answer

Traditional RBAC and ABAC struggle with deeply nested collaborative permissions (e.g. Google Drive: *"Allow edit if user is a member of Team X, which owns Folder Y, which contains Document Z"*). **Relationship-Based Access Control (ReBAC)** models authorization as a graph.

### Core Concepts (Google Zanzibar Model):
1. **Relation Tuples**: Represents relationships as discrete tuples:
   $$\langle 	ext{object} angle \# \langle 	ext{relation} angle @ \langle 	ext{subject} angle$$
   - *Example*: 'doc:file_101#viewer@user:alice'
   - *Example*: 'folder:tech#owner@group:engineering#member'
2. **Graph Evaluation**: Checks authorization by traversing relationship graph paths dynamically.

Key Takeaway: ReBAC models permissions as relationship tuple graphs, enabling complex nested collaboration access checks.

Question 36

How do you design a High-Availability Distributed Session Store using Redis Cluster?

Accepted Answer

Scaling stateful session authentication across high-traffic web apps requires a **High-Availability Redis Session Store**.

### Architectural Requirements:
1. **Redis Sentinel / Cluster Replication**: Primary Redis nodes handle active session writes, replicating asynchronously to Secondary replicas. Sentinel automatically promotes a replica if the primary crashes.
2. **Session Hash Data Structure**: Store session data as Redis hashes ('HSET session:s_9921 user_id "1042" roles "admin"').
3. **TTL Auto-Eviction**: Configure Redis key expiration ('EXPIRE session:s_9921 86400') so inactive sessions are automatically purged without manual database cleanup scripts.

Key Takeaway: High-availability session architectures use Redis Sentinel/Cluster with automatic key TTL eviction for instant failover.

Question 37

How do WebAuthn Registration and Authentication Ceremonies work technically?

Accepted Answer

W3C WebAuthn specifies two distinct cryptographic ceremonies between the Browser, Authenticator (TouchID/YubiKey), and Relying Party (Server):

### 1. Registration Ceremony:
1. Server generates a random challenge nonce and user info.
2. Browser calls 'navigator.credentials.create()'.
3. Authenticator generates a new key pair and returns a signed **Attestation Object** containing the public key.
4. Server verifies attestation signature and stores the public key alongside 'credentialId'.

### 2. Authentication Ceremony:
1. Server generates a random challenge.
2. Browser calls 'navigator.credentials.get()'.
3. Authenticator signs the challenge using its private key, returning an **Assertion Signature**.
4. Server verifies assertion signature using the stored public key.

Key Takeaway: WebAuthn registration creates and stores public keys; authentication verifies server challenges signed by hardware private keys.

Question 38

What is the OAuth 2.0 Device Authorization Grant (Device Flow / RFC 8628)?

Accepted Answer

The **OAuth 2.0 Device Authorization Grant** (RFC 8628) is designed for internet-connected devices that either lack a web browser or have restricted input capabilities (e.g. Smart TVs, GitHub CLI, Apple TV, gaming consoles).

### Execution Steps:
1. **Device Requests Code**: Device calls Auth Server '/device/code'.
2. **Device Displays Info**: Server returns a 'user_code' (e.g. 'WDJB-9921'), a 'verification_uri' ('https://company.com/activate'), and a 'device_code'.
3. **User Action**: User visits the URL on their smartphone or laptop and enters the 8-character code.
4. **Device Polling**: Meanwhile, the device polls the token endpoint ('/token') in the background until the user completes browser authentication, at which point the server returns access tokens to the device!

Key Takeaway: Device Flow allows browserless devices (CLI tools, Smart TVs) to obtain tokens via secondary smartphone browser authorization.

Question 39

How does the OAuth 2.0 Client Credentials Grant work for Machine-to-Machine (M2M) microservices?

Accepted Answer

When two backend microservices communicate without an active end-user present (e.g. a billing service contacting an inventory service), they use the **OAuth 2.0 Client Credentials Grant** (RFC 6749).

### M2M Execution Flow:
1. Microservice A sends a POST request directly to the Authorization Server token endpoint ('/oauth/token').
2. Transmits its own 'client_id' and 'client_secret' (or signed client JWT assertions) with 'grant_type=client_credentials'.
3. Auth Server verifies service credentials and issues a short-lived **M2M Access Token**.
4. Microservice A includes the access token in its 'Authorization: Bearer <token>' header when calling Microservice B.

Key Takeaway: Client Credentials Grant enables machine-to-machine microservices to authenticate directly using client secrets.

Question 40

What is Step-Up Authentication and how do you require re-authentication for high-risk actions?

Accepted Answer

Even if a user has an active valid session, executing high-risk sensitive operations (e.g. changing account email, transferring $10,000, viewing API keys) demands additional security validation. **Step-Up Authentication** handles this.

### Implementation Patterns:
1. **Authentication Context Class Reference ('acr') / Auth Time ('auth_time')**: The API checks how recently the user verified their password/MFA.
2. **Re-Authentication Challenge**: If 'auth_time' is older than 5 minutes, the API responds with a '401 Step-Up Required' challenge.
3. **Escalation**: User re-enters password or scans 2FA TOTP code to complete the sensitive action.

Key Takeaway: Step-Up Authentication re-prompts users for password or 2FA when attempting high-risk actions during an active session.

Question 41

What is OAuth 2.0 Token Exchange (RFC 8693) and how does it handle microservice delegation?

Accepted Answer

In microservice architectures, passing an incoming user access token directly through 10 internal downstream microservices violates the Principle of Least Privilege. **OAuth 2.0 Token Exchange** (RFC 8693) enables token transformation.

### How Token Exchange Works:
1. An edge microservice receives a high-privilege user access token.
2. Before calling an internal backend service, the edge service calls the Auth Server '/token' endpoint with 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange'.
3. Exchanges the original token for a **down-scoped internal access token** specifically audience-bound to the target internal microservice!

Key Takeaway: OAuth 2.0 Token Exchange (RFC 8693) down-scopes and re-binds tokens when passing requests between internal microservices.

Question 42

What is DPoP (Demonstrating Proof-of-Possession / RFC 9449) and how does it prevent token theft?

Accepted Answer

Standard Bearer tokens are vulnerable: if an attacker steals a valid Bearer token via network sniffing or server logs, they can replay it from any computer. **DPoP (Demonstrating Proof-of-Possession)** (RFC 9449) cryptographically binds tokens to a specific client.

### How DPoP Works:
1. Client generates a local ephemeral public/private key pair.
2. For **every API request**, the client generates a signed **DPoP Proof JWT** using its private key, attaching it in the 'DPoP: <proof_jwt>' header.
3. The DPoP Proof JWT contains HTTP Method, Request URI, and Nonce.
4. The API Server verifies that the access token is bound to the public key in the DPoP Proof JWT.
5. If an attacker steals the access token, it is completely useless without the client's private key!

Key Takeaway: DPoP cryptographically binds access tokens to client private keys, rendering stolen bearer tokens useless to attackers.

Question 43

How does Mutual TLS (mTLS) Client Certificate Authentication bind identity to TCP connections?

Accepted Answer

Standard TLS only authenticates the server to the client (one-way). **Mutual TLS (mTLS)** requires **both client and server to authenticate each other** using X.509 digital certificates during the initial TLS handshake.

### mTLS Handshake Mechanics:
1. **Server Certificate**: Server sends X.509 certificate; client validates against trusted root CAs.
2. **Certificate Request**: Server requests client certificate.
3. **Client Certificate**: Client presents its X.509 digital certificate.
4. **Validation**: Server verifies client certificate chain against internal private CA.
5. **Channel Binding**: Identity is bound directly to the encrypted TCP socket layer, completely bypassing application passwords!

Key Takeaway: mTLS authenticates both client and server via X.509 certificates during the TLS handshake, establishing zero-trust transport channels.

Question 44

How do you tune Argon2id parameters (memory cost m, time cost t, parallelism p)?

Accepted Answer

Argon2id (the OWASP recommended password hashing function) provides 3 configurable parameters to tune hashing performance and security:

### Argon2id Parameters:
1. **Memory Cost ('m')**: Amount of RAM (in KiB) consumed per hash computation (e.g. '65536 KiB = 64 MB'). High memory cost prevents hardware attackers from building custom ASIC/GPU mining rigs!
2. **Time Cost ('t')**: Number of execution iterations/passes over memory (e.g. 't = 3').
3. **Parallelism ('p')**: Number of compute threads used in parallel (e.g. 'p = 4').

### OWASP Tuning Rule of Thumb:
Target a calculation execution time of **~500 milliseconds** per password hash on production servers.

Key Takeaway: Tune Argon2id memory cost (64MB) and time cost to target ~500ms execution time, blocking GPU hardware brute-force.

Question 45

How do you securely implement User Impersonation for customer support teams?

Accepted Answer

Customer support engineers frequently need to log into an application **as a specific customer** to debug technical issues. Doing this by copying user passwords violates security principles. **Secure User Impersonation** handles this cleanly.

### Security Implementation Requirements:
1. **Explicit Permission**: Admin must possess 'users:impersonate' authorization.
2. **Short-Lived Impersonation Token**: Issue an explicit short-lived token (15 mins TTL).
3. **RFC 8693 Actor Claim ('act')**: The JWT MUST include both the target user ('sub') AND the support agent's identity ('act'):
   '{ "sub": "usr_customer101", "act": { "sub": "admin_agent42" } }'
4. **Audit Logging**: Log every action executed during impersonation tied to 'act.sub'.

Key Takeaway: Impersonation tokens must include explicit RFC 8693 actor claims (act) to maintain complete audit visibility of support agent actions.

Question 46

What are the security implications of domain-wide cookies (Domain=.example.com)?

Accepted Answer

When setting cookies, developers often set 'Domain=.example.com' so that authentication cookies automatically share across subdomains ('app.example.com', 'blog.example.com', 'forum.example.com').

### Severe Security Risk:
If a single low-security subdomain (e.g. an unmonitored WordPress instance on 'blog.example.com') suffers a **Cross-Site Scripting (XSS)** exploit, scripts running on 'blog.example.com' can read or overwrite the 'Domain=.example.com' authentication cookies for the main application on 'app.example.com'!

### Best Practice:
Omit the 'Domain' attribute entirely! Omitting 'Domain' restricts the cookie strictly to the **exact origin host** that set it, preventing subdomain XSS contamination.

Key Takeaway: Omit the Domain cookie attribute to restrict cookies to exact host origins, preventing subdomain XSS cookie leaks.

Question 47

How does Hierarchical RBAC implement role inheritance across permission trees?

Accepted Answer

In **Flat RBAC**, roles are independent lists of permissions. As an application grows, managing duplicated permissions across roles (e.g. 'Viewer', 'Editor', 'Admin', 'SuperAdmin') creates administrative burden. **Hierarchical RBAC** solves this via **Role Inheritance**.

### Role Inheritance Structure:
- **'Viewer'**: Holds 'posts:read'.
- **'Editor'** (inherits 'Viewer'): Automatically gets 'posts:read' + adds 'posts:write'.
- **'Admin'** (inherits 'Editor'): Automatically gets 'posts:read' + 'posts:write' + adds 'users:delete'.

### Permission Resolution:
Resolving permissions recursively traverses the role hierarchy parent-to-child links until matching the target permission.

Key Takeaway: Hierarchical RBAC allows child roles to inherit parent permissions, eliminating permission duplication across role definitions.

Question 48

How does Contextual Risk-Based Authentication adjust security policies based on IP/Location/Device?

Accepted Answer

Static authentication treats a login request from a user's normal home laptop the same as a login request coming from an anonymous Tor exit node in a foreign country. **Contextual Risk-Based Authentication (RBA)** dynamically assesses risk.

### Risk Signals Evaluated:
1. **Impossible Travel Velocity**: User logs in from New York, then 10 minutes later logs in from Tokyo.
2. **New Device / User-Agent Fingerprint**: Login from an unrecognized browser/device pair.
3. **Reputational IP Score**: Login from known botnets, VPNs, or datacenter IP blocks.

### Adaptive Policy Actions:
- **Low Risk (Score < 20)**: Grant seamless access.
- **Moderate Risk (20 - 70)**: Trigger mandatory Step-Up 2FA / WebAuthn prompt.
- **High Risk (Score > 70)**: Block access immediately and email security alert.

Key Takeaway: Contextual risk authentication dynamically triggers MFA challenges or blocks logins based on real-time threat signals.

Question 49

What is XML Signature Wrapping (XSW) in SAML 2.0 and how do you defend against it?

Accepted Answer

**XML Signature Wrapping (XSW)** is a major vulnerability class affecting SAML 2.0 authentication implementations. ### How XSW Attacks Work: 1. An attacker intercepts a legitimate, cryptographically signed SAML Response containing ''. 2. The attacker clones and injects a **forged unsigned assertion** ('') containing admin claims. 3. Due to flaws in flawed XML parsers, the **signature validator** verifies the valid signature on 'orig_100', but the **business logic parser** reads user identity from 'forged_999'! ### Mitigations: - Perform strict XML Schema validation before parsing. - Validate that the signed Assertion XML element is identical to the Assertion element evaluated by business logic. Key Takeaway: Defend against SAML XML Signature Wrapping by verifying that business logic reads the exact XML element validated by the signature.

Question 50

How does the OIDC /userinfo endpoint supply additional identity claims?

Accepted Answer

In OpenID Connect (OIDC), the **'/userinfo'** endpoint is a protected OAuth 2.0 Resource Server endpoint that returns detailed identity claims about the authenticated end-user.

### Execution Flow:
1. Client completes OIDC flow, receiving an Access Token with scopes (e.g. 'scope="openid profile email address"').
2. Client makes an HTTP GET or POST request to '/userinfo' passing 'Authorization: Bearer <access_token>'.
3. The server validates the access token, inspects granted scopes, and returns a JSON payload containing requested user claims ('email', 'email_verified', 'name', 'picture', 'locale').

Key Takeaway: The OIDC /userinfo endpoint accepts Bearer access tokens and returns detailed user profile identity claims filtered by granted scopes.

Question 51

What is Single Logout (SLO) in SAML and OIDC and how are back-channel notifications sent?

Accepted Answer

When a user logs out of a central Identity Provider (IdP), **Single Logout (SLO)** guarantees that active sessions across all federated Service Providers (SPs) are terminated simultaneously.

### Logout Mechanisms:
1. **Front-Channel Logout**: Uses browser iFrames or redirects to trigger logout URLs at each SP. Vulnerable if the user closes the browser mid-redirect.
2. **Back-Channel Logout (OIDC / SAML)**:
   - The IdP sends direct **server-to-server HTTP POST requests** to every registered SP's logout endpoint.
   - Transmits a signed **Logout Token** (JWT containing 'sub' or 'sid' session ID).
   - SP backends invalidate matching local session records immediately without relying on browser redirects!

Key Takeaway: Back-Channel Single Logout sends direct server-to-server HTTP notifications to invalidate sessions across federated service providers.

Question 52

How do you design a Multi-Tenant Auth system supporting custom Enterprise IdPs per tenant?

Accepted Answer

In B2B SaaS platforms, enterprise customers require signing in using their own custom Identity Providers (Okta, Azure AD) via SAML or OIDC. **Home Realm Discovery (HRD)** routes users to their specific tenant IdP.

### Routing Architecture:
1. **Domain Discovery**: User enters email ('alice@acme.com').
2. **Tenant Domain Match**: Server extracts domain ('acme.com') and looks up tenant configurations in DB.
3. **Dynamic IdP Redirection**:
   - If 'acme.com' has custom SAML configured, redirect to 'acme.okta.com'.
   - If no custom IdP, fallback to default password/passkey login.
4. **Tenant Context Assertion**: SAML/OIDC response is validated against the specific tenant's X.509 certificate or JWKS URL.

Key Takeaway: Multi-tenant auth uses Home Realm Discovery to route users to tenant-specific SAML/OIDC Identity Providers based on email domains.

Question 53

What is SCIM (System for Cross-domain Identity Management) 2.0 protocol?

Accepted Answer

While SAML/OIDC handle user *authentication*, **SCIM 2.0 (System for Cross-Domain Identity Management)** (RFC 7643 & 7644) automates **user identity lifecycle provisioning and de-provisioning**.

### Why SCIM is Essential:
Without SCIM, when an employee leaves an enterprise, admins must manually delete their account across 50 different SaaS tools. With SCIM:
1. Admin deactivates user in Okta / Azure AD.
2. Okta automatically dispatches a 'DELETE /Users/{id}' or 'PATCH /Users/{id}' ('active: false') HTTP request to all connected SaaS REST API endpoints.
3. SaaS backends deactivate user accounts instantly!

Key Takeaway: SCIM 2.0 is a standardized REST API specification for automating real-time user provisioning and de-provisioning from Identity Providers.

Question 54

How do you handle authentication securely in Next.js App Router Server Actions and Middleware?

Accepted Answer

In Next.js App Router, Server Actions expose POST endpoints accessible via public HTTP requests. Treating Server Actions like client-side functions without explicit authentication validation creates major vulnerabilities!

### Next.js Auth Architecture Rules:
1. **Never Trust Client Inputs**: Always validate authentication **inside the Server Action body** using 'cookies()' or session helpers.
2. **HttpOnly Cookie Retrieval**: Read httpOnly session cookies server-side.
3. **Session Verification**: Verify session token against Redis/DB before performing database mutations.

Key Takeaway: Always validate session tokens server-side inside Next.js Server Actions using httpOnly cookie getters.

Question 55

What was the JWT "none" algorithm vulnerability and how do modern libraries defend against it?

Accepted Answer

The **JWT '"none"' Algorithm Vulnerability** is one of the most famous flaws in early JWT library implementations:

### How the Exploit Worked:
1. Attacker takes a valid JWT, modifies the payload (changing 'role: "user"' to 'role: "admin"').
2. Attacker modifies the JWT header to '{"alg": "none"}' and strips the signature section.
3. Flawed JWT libraries saw '"alg": "none"', bypassed signature verification entirely, and trusted the forged admin claims!

### Modern Defenses:
Modern JWT verification functions **require an explicit algorithm whitelist** (e.g. 'algorithms: ['RS256']') and reject any token specifying '"none"' or un-approved algorithms.

Key Takeaway: Defend against JWT "none" and key confusion attacks by enforcing strict algorithm whitelists during token verification.

Question 56

How do you detect and mitigate Session Hijacking attempts?

Accepted Answer

**Session Hijacking** occurs when an attacker obtains a victim's valid session ID (via XSS, packet sniffing, or malware) and uses it to impersonate the victim.

### Mitigation & Detection Techniques:
1. **IP & User-Agent Fingerprint Binding**: Store client IP address and User-Agent hash alongside the session record. If incoming requests present a drastically different IP subnet or User-Agent, flag for re-authentication.
2. **Short Session Lifetimes & Activity Timeouts**: Expire inactive sessions after 15 minutes of idle time.
3. **Session Invalidation on Sensitive Network Shifts**: Force re-login if access shifts across geographic locations.

Key Takeaway: Detect session hijacking by binding sessions to client User-Agent fingerprints and IP subnet ranges.

Question 57

What is Cross-Site Script Inclusion (XSSI) and how do JSON prefixes prevent payload leaks?

Accepted Answer

**Cross-Site Script Inclusion (XSSI)** is a vulnerability where an attacker's website includes an authenticated API endpoint returning JSON data using a standard HTML '

Question 58

How does Refresh Token Reuse Detection automatically revoke compromised token families?

Accepted Answer

Standard long-lived refresh tokens create risks if stolen. **Refresh Token Rotation (RTR)** enforces that **every refresh token is strictly single-use**.

### Automatic Reuse Detection & Family Revocation:
1. When a client presents Refresh Token A, the Auth Server invalidates Token A and issues new Refresh Token B.
2. Tokens are grouped into a **Token Family ID**.
3. **Breach Scenario**: If an attacker steals Token A and tries to use it *after* the legitimate client has already exchanged it for Token B, the server detects **Refresh Token Reuse**!
4. **Automatic Response**: The Auth Server immediately revokes the **entire Token Family**, forcing all sessions (attacker and legitimate user) to log out instantly!

Key Takeaway: Refresh token reuse detection automatically revokes the entire token family if a previously used refresh token is presented again.

Question 59

How do Referrer-Policy headers prevent Authorization Bearer token leakage in GET requests?

Accepted Answer

Passing authentication tokens in URL query parameters ('GET /api/data?token=bearer_xyz') is an anti-pattern. If a user clicks an external link on that page, the browser attaches the full URL (including the query token!) in the outgoing HTTP 'Referer' header to the third-party site.

### Mitigations:
1. **Never Pass Tokens in Query Parameters**: Send tokens in HTTP 'Authorization: Bearer' headers or 'httpOnly' cookies.
2. **Enforce Referrer-Policy Header**:
   'Referrer-Policy: strict-origin-when-cross-origin'
   - Instructs browsers to strip path and query strings when navigating across origins, transmitting only the base origin ('https://company.com').

Key Takeaway: Set Referrer-Policy to strict-origin-when-cross-origin to prevent URL tokens from leaking via outgoing HTTP Referer headers.

Question 60

What is Keycloak and how does it act as an open-source Identity and Access Management (IAM) server?

Accepted Answer

**Keycloak** is a leading open-source Identity and Access Management (IAM) server maintained by Red Hat for modern applications and services.

### Key Features:
1. **Realms**: Isolated administrative domains managing users, roles, and applications.
2. **Protocol Support**: Native support for OpenID Connect (OIDC), OAuth 2.0, and SAML 2.0 out of the box.
3. **User Federation**: Syncs users directly from external Enterprise LDAP or Active Directory servers.
4. **Identity Brokering**: Enables social login (Google/GitHub) or enterprise SAML login without custom code.
5. **Out-of-the-box UI**: Pre-built login, registration, 2FA setup, and password reset flows.

Key Takeaway: Keycloak is an open-source IAM server providing out-of-the-box OIDC, SAML, LDAP user federation, and administration consoles.

Question 61

What is OAuth 2.0 Token Introspection (RFC 7662) and when should Resource Servers use it?

Accepted Answer

While JWTs can be verified locally using public keys, **Opaque Tokens** (random string handles) require querying the Authorization Server to check validity. **OAuth 2.0 Token Introspection** (RFC 7662) standardizes this lookup.

### Execution Flow:
1. Resource Server receives opaque token: 'Authorization: Bearer op_xyz123'.
2. Resource Server makes authenticated POST request to Auth Server '/introspect' endpoint.
3. Auth Server returns JSON metadata:
   '{ "active": true, "scope": "read write", "sub": "usr_1042", "exp": 1770000000 }'

### Trade-Offs:
- **Advantage**: Instant token revocation checks on every API request.
- **Drawback**: Introduces network latency bottleneck by querying the Auth Server on every API call.

Key Takeaway: OAuth 2.0 Token Introspection (RFC 7662) queries the Auth Server to check real-time validity of opaque access tokens.

Question 62

What is a Nested JWT (JWE containing a signed JWS) and when is it required?

Accepted Answer

Standard JWTs are **JWS (JSON Web Signature)** objects: signed to guarantee integrity, but Base64Url un-encrypted! If claims contain sensitive PII (SSNs, medical data), using plain JWS leaks data.

### Nested JWT Architecture (Signed THEN Encrypted):
1. **Inner JWS**: Payload claims are signed with the issuer's Private Key (guaranteeing authenticity).
2. **Outer JWE**: The signed JWS is then encrypted using the recipient's Public Key (guaranteeing confidentiality).
3. **Result**: Only the intended recipient holding the private decryption key can un-encrypt and verify the inner signed claims!

Key Takeaway: Nested JWTs sign claims with JWS and encrypt the wrapper with JWE, guaranteeing both authenticity and strict confidentiality.

Question 63

How do custom Authorization header schemes (Authorization: Signature ...) function?

Accepted Answer

RFC 7235 defines the standard syntax for the HTTP 'Authorization' request header:
$$	ext{Authorization} = 	ext{credentials} = 	ext{auth-scheme} + 	ext{SP} + 	ext{auth-param}$$

While 'Bearer' and 'Basic' are the most common schemes, applications can define **Custom Authentication Schemes** (e.g. 'Signature', 'Digest', 'HOBA', 'AWS4-HMAC-SHA256'):
'Authorization: AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20260727/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-date, Signature=fe5f...'

Custom schemes specify key-value authentication parameters directly in the header value for complex cryptographic request validation.

Key Takeaway: Custom Authorization header schemes format key-value parameters according to RFC 7235 for complex API signature validation.

Question 64

Compare storing tokens in sessionStorage vs IndexedDB vs Web Workers.

Accepted Answer

When storing access tokens client-side, security varies across browser storage mechanisms:

| Storage Type | Tab Lifetime | XSS Vulnerable? | Use Case |
|---|---|---|---|
| **'sessionStorage'** | Cleared on tab close | **YES** ('sessionStorage.getItem()') | Temporary non-sensitive UI state |
| **'IndexedDB'** | Persists across tabs | **YES** (Accessible to XSS scripts) | Large client offline databases |
| **'Web Worker RAM'** | Tab lifetime | **NO** (Isolated worker thread RAM) | Secure in-memory token storage |

### The Web Worker Pattern:
Storing access tokens inside an isolated **Web Worker thread** prevents main-thread DOM XSS scripts from reading token variables, while allowing the worker to attach tokens to outgoing 'fetch()' requests!

Key Takeaway: Web Workers isolate tokens in worker memory away from main-thread DOM XSS vulnerability vectors.

Take Authentication & Authorization Skill Assessment Quiz

Showing 100 Questions

1. Compare JWT Token Authentication versus Stateful Sessions, and explain OAuth 2.0 PKCE flow.

1. Stateful Sessions vs Stateless JWTs:

Storage Security Trade-Offs:

OAuth 2.0 PKCE Flow:

2. What is the fundamental difference between Authentication (AuthN) and Authorization (AuthZ)?

3. Why should passwords never be stored in plain text and how do bcrypt and Argon2id work?

4. How does traditional Cookie-Based Stateful Session Authentication work?

5. What are the 3 parts of a JSON Web Token (JWT) and how is the signature validated?

6. What is the difference between Access Tokens and Refresh Tokens?

7. What are the 4 core roles in the OAuth 2.0 Framework (RFC 6749)?

8. What is Single Sign-On (SSO) and what are its core architectural benefits?

9. What is Role-Based Access Control (RBAC) and how do Roles and Permissions map?

10. How does Two-Factor Authentication (2FA) using TOTP (Time-based One-Time Passwords) work?

11. How do SameSite Cookie attributes (Strict, Lax, None) defend against CSRF attacks?

12. Compare HTTP Basic Authentication versus Bearer Token Authentication.

13. What is OpenID Connect (OIDC) and how does it extend OAuth 2.0 for Identity?

14. What are Passkeys (WebAuthn / FIDO2) and how do they eliminate passwords?

15. What is Attribute-Based Access Control (ABAC) and how does it compare to RBAC?

16. Why must Access-Control-Allow-Credentials: true be configured carefully with CORS?

17. How does Passwordless Email Magic Link authentication work?

18. What are API Keys and when are they appropriate for service-to-service authentication?

19. What is a Session Fixation attack and how do you prevent it during login?

20. Why are the exp (Expiration Time), iat (Issued At), and nbf (Not Before) claims critical in JWTs?

21. How do you implement Logout for Stateful Sessions versus Stateless JWTs?

22. How do Cross-Domain SSO redirects exchange authentication tokens safely?

23. What is HMAC Request Signing and how does it prevent API payload tampering?

24. What is SAML 2.0 (Security Assertion Markup Language) and where is it used?

25. How does the Double Submit Cookie pattern defend against CSRF attacks?

26. Why are Account Lockout and Login Endpoint Rate Limiting necessary?

27. What are OAuth 2.0 Scopes and how do they restrict API access boundaries?

28. How does Social Login (Sign in with Google/GitHub) work via OAuth 2.0 and OIDC?

29. Why are Security Questions considered insecure compared to TOTP or Hardware Security Keys?

30. What does the HttpOnly cookie flag do and why does it prevent XSS token theft?

31. How do you implement OAuth 2.0 PKCE (Proof Key for Code Exchange) step-by-step?

32. What is the difference between Symmetric (HS256) and Asymmetric (RS256/ES256) JWT signing?

33. How do JWKS (JSON Web Key Sets) endpoints enable zero-downtime key rotation?

34. What is Open Policy Agent (OPA) and how does it decouple authorization policy from application code?

35. What is Relationship-Based Access Control (ReBAC) and the Google Zanzibar model?

36. How do you design a High-Availability Distributed Session Store using Redis Cluster?

37. How do WebAuthn Registration and Authentication Ceremonies work technically?

38. What is the OAuth 2.0 Device Authorization Grant (Device Flow / RFC 8628)?

39. How does the OAuth 2.0 Client Credentials Grant work for Machine-to-Machine (M2M) microservices?

40. What is Step-Up Authentication and how do you require re-authentication for high-risk actions?

41. What is OAuth 2.0 Token Exchange (RFC 8693) and how does it handle microservice delegation?

42. What is DPoP (Demonstrating Proof-of-Possession / RFC 9449) and how does it prevent token theft?

43. How does Mutual TLS (mTLS) Client Certificate Authentication bind identity to TCP connections?

44. How do you tune Argon2id parameters (memory cost m, time cost t, parallelism p)?

45. How do you securely implement User Impersonation for customer support teams?

46. What are the security implications of domain-wide cookies (Domain=.example.com)?

47. How does Hierarchical RBAC implement role inheritance across permission trees?

48. How does Contextual Risk-Based Authentication adjust security policies based on IP/Location/Device?

49. What is XML Signature Wrapping (XSW) in SAML 2.0 and how do you defend against it?

50. How does the OIDC /userinfo endpoint supply additional identity claims?

51. What is Single Logout (SLO) in SAML and OIDC and how are back-channel notifications sent?

52. How do you design a Multi-Tenant Auth system supporting custom Enterprise IdPs per tenant?

53. What is SCIM (System for Cross-domain Identity Management) 2.0 protocol?

54. How do you handle authentication securely in Next.js App Router Server Actions and Middleware?

55. What was the JWT "none" algorithm vulnerability and how do modern libraries defend against it?

56. How do you detect and mitigate Session Hijacking attempts?

57. What is Cross-Site Script Inclusion (XSSI) and how do JSON prefixes prevent payload leaks?

58. How does Refresh Token Reuse Detection automatically revoke compromised token families?

59. How do Referrer-Policy headers prevent Authorization Bearer token leakage in GET requests?

60. What is Keycloak and how does it act as an open-source Identity and Access Management (IAM) server?

61. What is OAuth 2.0 Token Introspection (RFC 7662) and when should Resource Servers use it?

62. What is a Nested JWT (JWE containing a signed JWS) and when is it required?

63. How do custom Authorization header schemes (Authorization: Signature ...) function?

64. Compare storing tokens in sessionStorage vs IndexedDB vs Web Workers.

65. How do you design a secure "Remember Me" persistent authentication feature?

66. How do you enrich JWT payloads with custom authorization claims without bloating token size?

67. How do you design a secure Password Reset token generation and verification flow?

68. Why should login Rate Limiting evaluate both IP address AND targeted User Account?

69. Why must the sub (Subject) claim in JWTs be an immutable static user ID?

70. What security attributes must be captured in Authentication Audit Logs?

71. How does Google Zanzibar achieve global consistency and microsecond authorization checks using Zookies?

72. How do Continuous Adaptive Risk and Authorization Assessment (CARTA) and Zero-Trust Architectures operate?

73. What is GNAP (Grant Negotiation and Authorization Protocol) and how does it succeed OAuth 2.0?

74. How do you validate FIDO2 Authenticator Attestation Statements (TPM, Android SafetyNet, Apple WebAuthn)?

75. What is Token Binding (RFC 8471) and how does TLS Exporter bind security tokens to underlying TLS keys?