Authentication & Authorization: JWT, OAuth, RBAC & Security

Authentication & Authorization

Why Engineers Care About This

Authentication answers "who are you?" Authorization answers "what can you do?" These are fundamental security concerns. When you get them wrong, you create vulnerabilities. When you get them right, you enable secure, scalable systems. Most security breaches come from authentication or authorization failures—weak passwords, missing authorization checks, token leaks, or privilege escalation.

When users can access data they shouldn't, or attackers can impersonate users, or tokens are leaked and reused, you're hitting authentication/authorization problems. These problems are often invisible until exploited. A missing authorization check might work fine in development (you're the only user), but allows data breaches in production. A weak token validation might seem fine until tokens are stolen and reused.

In interviews, when someone asks "How would you implement authentication?", they're really asking: "Do you understand the difference between authentication and authorization? Do you know how to implement secure, scalable auth? Do you understand token-based vs session-based auth?" Most engineers don't. They implement auth that works but isn't secure, or secure but doesn't scale.

Core Intuitions You Must Build

• Authentication is identity, authorization is permission. Authentication verifies who you are (username/password, API keys, OAuth tokens). Authorization checks what you can do (can this user access this resource?). These are separate concerns. A user can be authenticated (we know who they are) but not authorized (they can't access this resource). Design systems that separate these concerns—authenticate once, authorize on every request.

• Stateless authentication scales, stateful sessions don't. Server-side sessions require storing session state (usually in memory or a database). This creates bottlenecks—every request requires a session lookup, and sessions are server-specific (requiring sticky sessions for load balancing). Stateless authentication (JWT tokens) stores identity in the token itself, which clients send with each request. Servers verify tokens without lookups, enabling horizontal scaling.

• Tokens expire for security, refresh tokens for usability. Access tokens should have short expiration times (15 minutes to 1 hour) to limit damage if stolen. But short expiration creates poor UX (users re-authenticate frequently). Refresh tokens solve this—they're long-lived tokens that can be used to get new access tokens. When an access token expires, clients use the refresh token to get a new one without re-authenticating. This balances security (short-lived access tokens) with usability (long-lived refresh tokens).

• OAuth is delegation, not just "login with Google." OAuth lets users grant third-party applications limited access to their resources without sharing passwords. When you "login with Google," you're using OAuth—Google authenticates you, then gives the application a token with limited permissions. OAuth is about delegation: users control what applications can access. Understanding OAuth flows (authorization code, client credentials, device flow) helps you implement secure third-party integrations.

• RBAC is about roles, not individual permissions. Role-Based Access Control (RBAC) assigns permissions to roles, then assigns roles to users. Instead of checking "can user X do action Y?" you check "does user X have role Z, and does role Z allow action Y?" This scales better than individual permissions (you don't need to update every user when permissions change—just update the role). But RBAC requires careful role design—too many roles create complexity, too few roles create security gaps.

• Security is about defense in depth, not perfect systems. No single security measure is perfect. Passwords can be weak, tokens can be stolen, authorization checks can have bugs. Defense in depth means multiple layers of security: strong passwords + rate limiting + token expiration + authorization checks + audit logging. If one layer fails, others provide protection. Don't rely on a single security measure—use multiple layers.

Subtopics (Taught Through Real Scenarios)

Token-Based Authentication (JWT)

What people usually get wrong:

Engineers often think JWT tokens are "just encrypted user IDs." But JWTs are signed, not encrypted. The signature proves the token wasn't tampered with, but the payload is readable (it's base64-encoded, not encrypted). Don't store sensitive data in JWTs. Also, JWTs can't be revoked easily (they're stateless). If a token is stolen, you can't "invalidate" it until it expires. This is why short expiration times matter—they limit the window of vulnerability.

How this breaks systems in the real world:

An API used JWTs with 30-day expiration. A token was stolen (leaked in logs, copied from browser storage). The attacker used the token for 30 days, accessing the user's data. The user changed their password, but the token still worked (JWTs are stateless—password changes don't invalidate tokens). The fix? Use shorter expiration times (1 hour), implement refresh tokens, and add token blacklisting for critical operations (logout, password change). But the real lesson is: JWTs are stateless, which enables scaling but limits revocation. Design for this trade-off.

What interviewers are really listening for:

They want to hear you talk about JWT structure (header, payload, signature), stateless vs stateful auth, and token revocation challenges. Junior engineers say "JWTs are encrypted tokens." Senior engineers say "JWTs are signed tokens with readable payloads, they're stateless which enables scaling but limits revocation, and you need short expiration times and refresh tokens." They're testing whether you understand that JWTs are a trade-off between scalability and revocation.

OAuth 2.0 Flows

What people usually get wrong:

Engineers often think OAuth is "just login with Google/Facebook." But OAuth is about delegation—letting users grant third-party applications limited access to their resources. OAuth has multiple flows: authorization code (for web apps), client credentials (for server-to-server), device flow (for devices without browsers). Each flow is for different use cases. Don't use the wrong flow—it creates security vulnerabilities or poor UX.

How this breaks systems in the real world:

A mobile app used the authorization code flow, but implemented it incorrectly. The app received the authorization code, then sent it to the app's backend to exchange for tokens. But the redirect URI wasn't validated properly, allowing attackers to intercept authorization codes. The fix? Use PKCE (Proof Key for Code Exchange) for mobile apps, validate redirect URIs strictly, and use the device flow for devices without browsers. But the real lesson is: OAuth flows are complex, and implementing them incorrectly creates vulnerabilities. Use well-tested libraries when possible.

What interviewers are really listening for:

They want to hear you talk about different OAuth flows, when to use each, and security considerations. Junior engineers say "OAuth is just login with Google." Senior engineers say "OAuth is about delegation with multiple flows (authorization code, client credentials, device flow), each for different use cases, and security requires proper redirect URI validation and PKCE for mobile apps." They're testing whether you understand that OAuth is more than "login with Google"—it's a delegation protocol with multiple flows and security considerations.

Role-Based Access Control (RBAC)

What people usually get wrong:

Engineers often implement authorization as "if user ID == resource owner, allow." This works for simple cases, but doesn't scale. What if admins need access? What if users need to share resources? RBAC solves this by assigning permissions to roles, then roles to users. But RBAC requires careful design—too many roles create complexity, too few roles create security gaps. Also, RBAC doesn't handle dynamic permissions well (permissions based on resource state, not just user role).

How this breaks systems in the real world:

A system had three roles: user, admin, superadmin. This worked initially. But as the system grew, they needed more granular permissions (some admins should manage users but not billing, some should manage billing but not users). They added more roles (user-admin, billing-admin, etc.), creating role explosion (20+ roles). Managing roles became complex, and users often had multiple roles. The fix? Use attribute-based access control (ABAC) or policy-based access control (PBAC) for complex permissions, or implement hierarchical roles. But the real lesson is: RBAC works for simple permission models, but complex permissions require more sophisticated approaches.

What interviewers are really listening for:

They want to hear you talk about RBAC vs individual permissions, role design, and when RBAC isn't enough. Junior engineers say "just check if user is admin." Senior engineers say "RBAC assigns permissions to roles then roles to users, it scales better than individual permissions but requires careful role design, and complex permissions may need ABAC or PBAC." They're testing whether you understand that authorization is about more than "is user admin?"—it's about designing permission models that scale.

API Key Management

What people usually get wrong:

Engineers often think API keys are "just strings that identify clients." But API keys are credentials—they authenticate clients and should be treated as secrets. Don't log API keys, don't commit them to version control, don't send them in URLs (they appear in logs). Also, API keys should be scoped (limited permissions) and rate-limited. A leaked API key with full permissions is a security vulnerability. A leaked API key with read-only permissions and rate limits is less dangerous.

How this breaks systems in the real world:

An API used API keys for authentication, but didn't scope them. All API keys had full permissions (read, write, delete). A key was leaked (committed to a public GitHub repository). Attackers used the key to access and delete data. The fix? Scope API keys (read-only, write-only, admin), implement rate limiting per key, rotate keys regularly, and monitor for unusual activity. But the real lesson is: API keys are credentials. Treat them as secrets, scope them appropriately, and monitor their usage.

What interviewers are really listening for:

They want to hear you talk about API key security, scoping, and management. Junior engineers say "API keys are just strings." Senior engineers say "API keys are credentials that should be scoped, rate-limited, rotated regularly, and monitored for unusual activity." They're testing whether you understand that API keys are more than identifiers—they're credentials that need proper security practices.

---

• Authentication verifies identity, authorization checks permissions—these are separate concerns
• Stateless authentication (JWT) scales better than stateful sessions
• Tokens should expire quickly, refresh tokens enable usability without sacrificing security
• OAuth is about delegation—understand different flows for different use cases
• RBAC scales better than individual permissions but requires careful role design
• API keys are credentials—treat them as secrets, scope them, and monitor usage
• Security is defense in depth—use multiple layers of protection
• Use well-tested libraries for authentication/authorization—implementing them incorrectly creates vulnerabilities

---

• API Design - Designing secure APIs
• Networking - HTTPS, TLS, and secure communication
• System Design - Scalable authentication architectures