10 Auth Patterns for Pune Full Stack Devs (2026)

The list

1. 1

   Password hashing with bcrypt / argon2 (never plaintext)

   Use bcrypt (cost factor 10-12) or argon2 (the modern recommendation) to hash passwords before storage. Never store plaintext, never store with MD5/SHA-256 alone (too fast → brute-forceable). bcrypt is universally supported; argon2 is more memory-hard + future-proof.

   Why it matters: Asked at ~80% of Pune auth rounds. 'How do you store passwords?' — if 'hashed' is your only answer, you fail. Specifying bcrypt cost factor or argon2 signals real security understanding.

   Best for: Foundation; every user-storing app needs this.

2. 2

   JWT for stateless authentication

   Server signs a token (header.payload.signature); client stores it + sends with each request. Server verifies signature without database lookup → stateless. Token payload typically: user_id, roles, exp. Signing algorithm: HS256 (symmetric) for single service, RS256 (asymmetric) for distributed systems.

   Why it matters: Asked at ~85% of Pune full-stack rounds. Walk through the verify flow + signing algorithm trade-offs.

   Best for: API authentication; mobile clients; microservices internal auth.

3. 3

   Access + refresh token pattern

   Access token (short-lived, ~15 min) for API calls; refresh token (long-lived, ~7 days) stored httpOnly cookie for getting new access tokens. When access token expires, client uses refresh to get new pair. Refresh token rotation: invalidate old refresh on use to prevent replay attacks.

   Why it matters: Asked at ~70% of Pune product company rounds. The dominant fresher production auth pattern; mention rotation + httpOnly + SameSite + Secure for senior-fresher signal.

   Best for: Production-grade JWT-based auth; web apps.

4. 4

   OAuth 2.0 + OIDC for third-party login (Google, Microsoft, GitHub)

   OAuth 2.0 = authorization (give X app access to my Y data). OpenID Connect = OAuth 2.0 + identity layer (who am I). Authorization Code Flow with PKCE is the modern default for web + mobile + SPA. Don't use Implicit Flow (deprecated for security reasons).

   Why it matters: Asked at ~55% of Pune product company rounds. Authorization Code Flow + PKCE = the answer; specifying these signals real OAuth understanding.

   Best for: Social login; SSO; third-party integrations.

5. 5

   Role-Based Access Control (RBAC)

   Define roles (admin, editor, viewer); assign permissions to roles; assign roles to users. Check role at endpoint: `if user.role != 'admin' return 403`. Simple model; works for most apps. Common Pune codebases: middleware checks roles before reaching the handler.

   Why it matters: Asked at ~60% of Pune rounds. Foundation authorization pattern; expected to know.

   Best for: Most applications; simple permission models.

6. 6

   Attribute-Based Access Control (ABAC)

   Beyond role: check attributes of user + resource + context. Example: 'user can edit document IF user.department == document.department AND time.hour < 18'. More flexible than RBAC; handles 'tenant isolation', 'team-based access', 'time-bound permissions'. Implementation: policy engines like OPA (Open Policy Agent), Casbin, or library-specific.

   Why it matters: Asked at ~30% of Pune product company + BFSI rounds. Senior-fresher signal; rare at services-major fresher tier.

   Best for: Multi-tenant SaaS; fine-grained permissions; BFSI compliance contexts.

7. 7

   Session-based auth (still relevant)

   Server stores session in Redis / database / memory; sets cookie with session ID. On each request, server looks up session via cookie. Stateful (server tracks all logged-in users) but simpler + more secure for many web apps (easy revocation, no client-side token mgmt).

   Why it matters: Asked at ~45% of Pune rounds. Common follow-up: 'JWT vs session — when each?' (JWT for distributed/mobile/API; sessions for monolithic web apps where revocation matters).

   Best for: Server-rendered web apps; cases needing immediate revocation.

8. 8

   Multi-Factor Authentication (MFA / 2FA)

   Beyond password: second factor like TOTP (Time-based One-Time Password via Google Authenticator/Authy), SMS code (less secure due to SIM swap risk), or hardware key (FIDO2/WebAuthn). TOTP via library (pyotp, otplib) is the safe default. Critical for any sensitive application.

   Why it matters: Asked at ~40% of Pune product company + BFSI rounds. Implementing TOTP correctly signals security maturity.

   Best for: Any application with sensitive user data; BFSI requirements.

9. 9

   API Key management for service-to-service auth

   Internal services authenticate to each other via API keys (rotated regularly) or mTLS or service mesh (Istio). Don't share API keys across services — each service gets its own with scoped permissions. Use environment-based config; never commit keys to git; rotate on suspected compromise.

   Why it matters: Asked at ~35% of Pune backend rounds. Common production-deployment question at modern Pune product cos.

   Best for: Service-to-service authentication; microservices; integration with external APIs.

10. 10

    CORS for cross-origin browser security

    Browser-enforced policy: JS on origin A can't call API on origin B unless B explicitly allows via Access-Control-Allow-Origin headers. Specify exact origins (not *) for credentialed requests. Common Pune full-stack project gotcha: frontend on localhost:3000, backend on localhost:8080 → CORS errors.

    Why it matters: Asked at ~50% of Pune full-stack rounds. Most fresher candidates have hit CORS errors in dev; explain the security reason behind it, not just 'add CORS middleware'.

    Best for: Any web app with separate frontend + backend origins.