LogoBytesFor Developers
HomeBytesheetsRoadmapsUI TemplatesUI ToolsStack Discussion
50 Topics
Chapter•480 Minutes

Complete Interview Questions & Answer Bank

50 curated technical interview questions and answers covering authentication fundamentals, JWT mechanics, OAuth 2.0 grant types, OIDC specifications, security vulnerabilities, and production architecture patterns.

Q1: What is the fundamental difference between Authentication and Authorization?

Difficulty:EasyTopic:Fundamentals

Authentication (AuthN) is the process of verifying who a user or system is. It confirms identity through credentials like passwords, biometrics, or cryptographic keys.

Authorization (AuthZ) is the process of verifying what an authenticated user or system is permitted to do. It checks rights, roles, and scopes before granting access to specific resources.

AuthN vs AuthZ Comparison
Core Purpose: Identity Verification vs Permission Control
AuthN answers 'Who are you?'; AuthZ answers 'What are you allowed to access?'
Protocols: OIDC, SAML, WebAuthn vs OAuth 2.0, RBAC, ABAC
OpenID Connect is built for AuthN, while OAuth 2.0 is strictly an AuthZ protocol.
Tokens Used: ID Token vs Access Token
ID Tokens contain user profile claims; Access Tokens contain scopes and permissions.
Key Takeaways
  • Authentication validates identity (Who you are); Authorization validates permissions (What you can do).
  • OAuth 2.0 is an authorization framework, whereas OpenID Connect adds an authentication layer on top of it.

Q2: What is a JSON Web Token (JWT) and what are its three structural components?

Difficulty:EasyTopic:JWT Basics

A JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained format for securely transmitting information between parties as a JSON object.

A JWT consists of three parts separated by dots (.):

  1. Header: Specifies the token type (JWT) and signing algorithm (HS256, RS256).
  2. Payload: Contains the claims (statements about an entity, e.g., user ID, roles, expiration time).
  3. Signature: Cryptographic signature generated by combining the Base64URL-encoded header and payload with a secret or private key.
JWT String Structure and Decoded Components
// Base64URL Encoded JWT String:
// eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

// Decoded Header:
{
  "alg": "HS256",
  "typ": "JWT"
}

// Decoded Payload:
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}
💡 Header and Payload are Base64URL encoded JSON strings. The signature is computed using the secret key over the encoded header and payload.
Key Takeaways
  • A JWT consists of three Base64URL encoded strings separated by dots: Header, Payload, and Signature.
  • JWT payloads are encoded, not encrypted by default; sensitive raw data must never be placed inside a standard JWT.

Q3: What are the standard JWT Registered Claims and their definitions?

Difficulty:EasyTopic:JWT Claims

RFC 7519 defines a set of optional, standardized claim keys known as Registered Claims to ensure interoperability across applications:

  • iss (Issuer): Identifies the principal that issued the JWT.
  • sub (Subject): Identifies the principal that is the subject of the JWT (e.g., User ID).
  • aud (Audience): Identifies the recipients that the JWT is intended for.
  • exp (Expiration Time): Identifies the expiration time on or after which the JWT MUST NOT be accepted.
  • nbf (Not Before): Identifies the time before which the JWT MUST NOT be accepted.
  • iat (Issued At): Identifies the time at which the JWT was issued.
  • jti (JWT ID): Provides a unique identifier for the JWT (used to prevent replay attacks).
Key Takeaways
  • Registered claims are standardized shorthand keys designed for interoperable security checks.
  • Always enforce exp validation on backend resource servers to limit the exposure window of compromised tokens.

Q4: What is the difference between Symmetric (HS256) and Asymmetric (RS256) JWT signing?

Difficulty:MediumTopic:Cryptography
  • HS256 (HMAC with SHA-256): Uses a single shared secret key for both signing and verifying the token. Both the Auth Server and Resource Server must share and store the identical secret key securely.
  • RS256 (RSA Signature with SHA-256): Uses an asymmetric key pair. The Authorization Server signs the JWT using its Private Key, while external Resource Servers verify the signature using the Authorization Server's public key (fetched via JWKS).
RS256 Asymmetric Verification Architecture
Key Takeaways
  • HS256 requires sharing secret keys between Auth Server and APIs; RS256 requires exposing only public keys.
  • RS256 is the industry standard for microservice architectures and third-party API consumers.

Q5: Compare Stateful Session Authentication with Stateless JWT Authentication.

Difficulty:MediumTopic:Architecture Patterns

In Stateful Session Authentication, the server generates a random Session ID upon login, stores session state in memory/database (e.g., Redis), and returns the Session ID in an HTTP cookie. On each request, the server looks up the Session ID in the database.

In Stateless JWT Authentication, all user context and permissions are encoded directly inside the signed JWT payload returned to the client. Resource servers validate the token cryptographically without making database lookups.

Sessions vs JWTs
State Management: Server-side Database vs Client-side Payload
Sessions require centralized cache lookups; JWTs self-contain user state.
Revocation Speed: Instant (Delete session record) vs Complex (Requires blacklist)
Session revocation takes effect immediately; JWTs remain valid until exp unless blacklisted.
Horizontal Scalability: Requires Shared Session Store vs Inherently Scalable
JWTs allow any microservice instance to validate requests independently.
Key Takeaways
  • Session authentication enables instant server-side revocation but creates database lookup bottlenecks.
  • JWT authentication scales effortlessly across microservices but complicates token revocation.

Q6: What are the four core roles defined in the OAuth 2.0 framework (RFC 6749)?

Difficulty:EasyTopic:OAuth 2.0 Basics

OAuth 2.0 defines four distinct roles to separate token authorization from resource handling:

  1. Resource Owner: The entity capable of granting access to a protected resource (typically the end user).
  2. Resource Server: The API server hosting the protected user resources, capable of accepting and responding to protected resource requests using access tokens.
  3. Client: The application making resource requests on behalf of the Resource Owner with its authorization.
  4. Authorization Server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
Key Takeaways
  • OAuth 2.0 strictly decouples the Authorization Server from the Resource Server.
  • Clients interact with Resource Servers strictly using access tokens issued by the Authorization Server.

Q7: Explain the OAuth 2.0 Authorization Code Flow with PKCE.

Difficulty:AdvancedTopic:OAuth Grant Flows

Proof Key for Code Exchange (PKCE, RFC 7636) secures the Authorization Code flow for public clients (SPAs, Mobile Apps) against authorization code interception attacks.

PKCE Protocol Steps:

  1. Client creates a random string code_verifier and computes code_challenge = BASE64URL(SHA256(code_verifier)).
  2. Client redirects user to Authorization Server passing code_challenge and code_challenge_method=S256.
  3. User authenticates and grants access; Authorization Server redirects back with an authorization_code.
  4. Client exchanges authorization_code + original code_verifier at the token endpoint.
  5. Authorization Server hashes the provided code_verifier and verifies it matches the stored code_challenge before returning access tokens.
OAuth 2.0 Authorization Code Flow + PKCE Sequence
Key Takeaways
  • PKCE replaces client secrets for public clients (Mobile apps, Single Page Applications).
  • The authorization code cannot be exchanged for tokens without presenting the matching unhashed code_verifier.

Q8: What are the main OAuth 2.0 Grant Types and when should each be used?

Difficulty:MediumTopic:OAuth Grant Flows

OAuth 2.0 provides several grant types tailored for different application architectures:

  • Authorization Code Grant + PKCE: For Single Page Apps (SPAs), Mobile Apps, and Web Applications.
  • Client Credentials Grant: For machine-to-machine (M2M) communication without user context.
  • RefreshToken Grant: Used by clients to obtain new access tokens when current access tokens expire.
  • Resource Owner Password Credentials (Deprecated): Legacy flow where user gives credentials directly to client; strictly disallowed in OAuth 2.1.
  • Implicit Grant (Deprecated): Legacy SPA flow that returned tokens in URL fragments; completely removed in OAuth 2.1 in favor of PKCE.
Key Takeaways
  • Authorization Code + PKCE is the universal standard for user-facing applications.
  • Client Credentials Grant is intended exclusively for server-to-server daemon processes.

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

Difficulty:MediumTopic:OAuth Grant Flows

The Client Credentials Grant is used when the client application requests access to resources under its own control, rather than requesting access to a specific user's private data.

Execution Flow:

  1. The confidential client transmits its client_id and client_secret directly to the Authorization Server's /token endpoint using HTTP Basic Auth or request body parameters (grant_type=client_credentials).
  2. The Authorization Server authenticates the client credentials.
  3. The Authorization Server issues an Access Token containing application-level scopes.
  4. The client uses the Access Token to call backend APIs.
Client Credentials Token Request Payload
POST /oauth/token HTTP/1.1
Host: auth.example.com
Authorization: Basic Y2xpZW50X2lkOmNsaWVudF9zZWNyZXQ=
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&scope=read%3Areports%20write%3Alogs
💡 The client authenticates using its secret and requests access tokens bound to machine-level API scopes.
Key Takeaways
  • Client Credentials Grant involves no end-user interaction or browser redirects.
  • Must be used strictly by confidential backend servers capable of securing client secrets.

Q10: What is OpenID Connect (OIDC) and how does it extend OAuth 2.0?

Difficulty:MediumTopic:OpenID Connect

OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 framework. While OAuth 2.0 handles authorization (granting access keys to resources), OIDC extends it to perform user authentication.

OIDC Additions to OAuth 2.0:

  • ID Token: A standardized JWT containing user identity profile attributes (claims like sub, email, name).
  • UserInfo Endpoint: A protected API endpoint returning detailed user profile attributes.
  • Standardized Scopes: Predefined scopes like openid, profile, email.
Key Takeaways
  • OIDC = OAuth 2.0 (Authorization) + ID Token (Authentication).
  • Always include the openid scope in authorization requests to trigger OIDC behavior.

STAY UPDATED WITH BYTES!

© 2026 Bytes4Dev. All rights reserved.

v.0.4.0