인증·인가 — 백엔드 면접 (실제 기출 기반·심화)

한국 백엔드 면접에서 거의 무조건 나온다. "쿠키와 세션의 차이", "Stateless인데 세션은 적절한가", "서버가 여러 대면 세션을 어떻게", "JWT가 탈취되면", "OAuth는 인증인가 인가인가", "CSRF/XSS" — 단골이고, VSFe 패턴으로 무효화·확장·보안 트레이드오프까지 4단으로 파고든다.

면접관이 노리는 함정: ① JWT는 암호화? → 인코딩(누구나 디코드) ② OAuth는 인증? → 인가(인증은 OIDC) ③ 순수 JWT는 로그아웃 즉시 무효화? → 불가.

---

1. 인증 vs 인가·Stateless (★★ 단골)

실제 질문: "인증과 인가의 차이는?" · "HTTP의 Stateless를 설명하라(쿠키/세션이 왜 필요한가)." (VSFe·gyoogle)

• 인증(Authentication) = "너 누구야"(신원·로그인). 인가(Authorization) = "너 이거 해도 돼"(권한). 섞으면 감점.
• HTTP는 각 요청이 서로를 모른다(Stateless·Connectionless) → 로그인 연속성을 세션(서버 기억) 또는 **토큰(클라가 들고 다님)**으로 얹는다.

꼬리질문: "Stateless인데 어떻게 로그인 유지?" → 매 요청에 *증명(세션ID/토큰)*을 실어 보냄. / "인가는 어디서?" → 게이트웨이·서비스·메서드(@PreAuthorize).

---

2. 쿠키·세션·확장 (★★★ 단골·4단 꼬리)

실제 질문: "쿠키와 세션의 차이는?" · "세션 로그인 과정을 설명하라." · "Stateless의 의미를 보면 세션은 적절하지 않은 인증 아닌가요?" · "서버가 여러 개가 되면 세션을 어떻게 관리하나요?" (VSFe 4단)

• 쿠키(클라 저장·4KB·보안 약함) vs 세션(서버 저장·세션ID만 쿠키로 전달). 세션도 쿠키를 쓴다(세션ID 운반).

깊이 — 서버 여러 대면(★ 핵심 꼬리): 세션은 서버 메모리에 있어 스케일아웃 시 세션 불일치(A서버 로그인 → B서버 요청 시 없음). → ① Sticky Session(같은 서버로 고정·서버 죽으면 유실) ② 세션 클러스터링(서버 간 복제) ③ Redis 세션 스토어(외부 공유·표준).

꼬리질문: "세션은 쿠키를 안 쓰나?" → 쓴다(세션ID). / "Stateless라 세션이 부적절?" → 서버가 상태를 갖긴 하나, 클라는 ID만 들고 다녀 절충. 완전 무상태는 JWT.

함정: ❌ "세션은 쿠키를 안 쓴다" → 세션ID를 쿠키로. ❌ "세션은 스케일아웃이 자유롭다" → 공유 스토어 필요.

---

3. JWT — 구조·무효화 (★★★ 단골)

실제 질문: "JWT 인증 방식이 무엇인가요?" · "Signature는 어떻게 만들어지나요?" · "Access Token이 탈취되면? 반대로 Refresh Token이 탈취되면?" (VSFe 3단)

header.payload.signature
header  = {typ, alg}
payload = 클레임(iss·sub·exp·iat·jti) ← base64url 인코딩(암호화 아님)
signature = 서명( base64url(header) + "." + base64url(payload), 키 )
            // HMAC=대칭 비밀키, RSA/ECDSA=개인키 서명·공개키 검증

• base64url 인코딩(암호화 아님) → ⚠️ payload는 누구나 디코드 → 민감정보 금지. 서명만 위변조 검증 → DB 조회 없이 인증(무상태).

깊이 — 무효화가 어렵다(★ 핵심): JWT는 서버가 상태를 안 가져 로그아웃·탈취 시 즉시 못 막는다(만료 전까지 유효). → ① 짧은 Access(15분~1h) + Refresh(길게·서버 저장) ② Redis 블랙리스트(서버 상태 부활) ③ Refresh Token Rotation(갱신마다 새 발급·옛것 폐기 → 재사용 감지 시 유출 판단).

꼬리질문: "Access 탈취 대응?" → 짧은 만료로 피해 최소화·refresh로 회전. / "Refresh 탈취?" → 회전 + 재사용 감지 시 전체 무효화·디바이스 바인딩. / "JWT가 세션보다 좋은 점?" → 무상태·MSA 확장(서명키만 공유) / 나쁜 점 = 무효화.

함정: ❌ "JWT는 암호화되어 안전" → 인코딩(디코드 가능)·민감정보 금지. ❌ "순수 JWT는 즉시 로그아웃 가능" → 블랙리스트 같은 서버 상태 필요.

---

4. OAuth 2.0·OIDC (★★ 단골)

실제 질문: "OAuth는 인증인가요 인가인가요?" · "OAuth 흐름을 설명하라." (VSFe·gyoogle)

• OAuth 2.0 = 인가 위임(비번을 제3자 앱에 안 주고 권한만 허락). 인증이 아니다 → 신원은 그 위 **OIDC(OpenID Connect)**가 **id_token(JWT)**로 제공.
• Authorization Code Grant(웹/앱 표준): 인가 요청 → Authorization Code → (서버에서) Access Token 교환. PKCE(code_verifier/challenge)로 코드 가로채기 방지.

꼬리질문: "OAuth로 로그인했으니 인증?" → OAuth 자체는 인가, 로그인은 OIDC 레이어. / "Implicit Grant가 deprecated된 이유?" → 토큰이 URL에 노출 → Auth Code+PKCE. / "PKCE는 왜?" → 공개 클라이언트(앱·SPA)의 코드 탈취 방지.

함정: ❌ "OAuth로 로그인 = 인증" → 인가(인증은 OIDC).

---

5. 인가 — RBAC·인가 위치 (★ 기출)

실제 질문: "권한 관리를 어떻게 설계하나요?"(RBAC)

• RBAC(역할 기반): 사용자→역할(ADMIN·USER)→권한. 단순·흔함(Spring Security hasRole). ABAC(속성 기반): 부서·시간·소유자 등 세밀한 정책.

꼬리질문: "인가는 어디서?" → 게이트웨이·서비스·메서드. / "MSA 인증?" → 게이트웨이가 토큰 검증 후 전파(또는 mTLS).

---

6. 쿠키 보안·CSRF·XSS·비밀번호 (★★ 단골)

실제 질문: "JWT/토큰을 어디에 저장하나요?(쿠키 vs 웹스토리지)" · "CSRF와 XSS를 어떻게 막나요?" · "비밀번호를 어떻게 저장하나요?" (velog·gyoogle)

• 저장 위치 트레이드오프(★): 웹스토리지(localStorage)는 XSS에 취약(JS가 읽음), 쿠키는 CSRF에 취약(자동 전송). → 실전 권장: HttpOnly + Secure + SameSite 쿠키 + CSRF 토큰 + 짧은 만료 + 회전을 겹겹이.
• CSRF: 쿠키 자동 전송 악용 → SameSite + CSRF 토큰(Double Submit). XSS: 스크립트 주입 → 출력 이스케이프·CSP·HttpOnly.
• 비밀번호 저장: 평문·단순 해시(MD5/SHA) 금지(레인보우·고속 brute-force) → 느린 해시 + salt(사용자별 랜덤)·선택 pepper. OWASP 1순위는 Argon2id, bcrypt는 legacy(입력 72바이트 제한 주의), scrypt.

꼬리질문: "HttpOnly가 막는 공격?" → JS의 토큰 유출(XSS)만 막음 — XSS 자체나 CSRF는 못 막아 CSRF 토큰 병행. / "SameSite=Strict 부작용?" → 외부 링크 진입 시 로그인 풀림. / "왜 bcrypt가 SHA보다 안전?" → 의도적으로 느려 brute-force 비용↑(work factor). / "salt vs pepper?" → salt는 사용자별(DB), pepper는 앱 시크릿(외부).

함정: ❌ "JWT는 localStorage가 안전" → XSS 취약. ❌ "단순 SHA로 비번 저장하면 됨" → 느린 해시+salt.

---

흔한 오답·함정 정리

• JWT는 암호화되어 안전 → 인코딩(디코드 가능)·민감정보 금지.
• OAuth = 인증 → 인가(인증은 OIDC).
• 순수 JWT 즉시 로그아웃 가능 → 블랙리스트 등 서버 상태 필요.
• 세션은 쿠키 안 씀 → 세션ID를 쿠키로.
• JWT를 localStorage에 두면 안전 → XSS 취약(HttpOnly 쿠키 재고).

한국 면접 단골 Q&A (답변 골격)

꼬리질문 대비 (상 난이도)

• "로그아웃을 어떻게 구현?(JWT)" → Refresh 폐기 + Access 블랙리스트(짧은 만료라 보통 만료 대기).
• "Redis 세션 죽으면?" → 가용성·복제·세션 유실 → Sentinel/Cluster.
• "MSA에서 인증?" → 게이트웨이 토큰 검증 + 전파(또는 mTLS).
• "PKCE 흐름?" → code_challenge 전송 → 토큰 교환 시 code_verifier 검증.
• "세션 고정 공격?" → 로그인 시 세션ID 재발급.

한 줄 요약 — 인증(누구)≠인가(권한·RBAC/ABAC). HTTP Stateless라 세션(서버·쿠키로 세션ID·스케일아웃은 Redis 세션 스토어) 또는 JWT(무상태·확장·무효화 어려움→짧은 access+refresh 회전·블랙리스트). JWT payload는 인코딩(암호화 아님). OAuth=인가(신원은 OIDC). 쿠키 HttpOnly·Secure·SameSite, CSRF=SameSite+토큰·XSS=이스케이프/CSP/HttpOnly, 비번=bcrypt/Argon2+salt.

(출처 — 한국 면접 기출·교차검증 2026-06: VSFe/Tech-Interview — Network·ETC·gyoogle — JWT/OAuth/Cookie&Session·shinminsoo JWT+Redis 토큰 전략 · RFC 7519(JWT)·RFC 6749(OAuth 2.0)·OpenID Connect Core·OWASP Password Storage Cheat Sheet 교차검증.)