티스토리 뷰

반응형

✅ 압박면접 대응 시리즈 21편: JWT 인증 구조와 Refresh Token 기반 보안 설계

압박면접에서 “JWT는 어떻게 동작하나요?”, “Refresh Token을 왜 사용하나요?”라는 질문은
백엔드 지식과 프론트엔드 실무 감각을 동시에 평가하는 질문입니다.
면접관은 당신이 단순히 “로그인 토큰으로 씁니다” 수준이 아니라,
토큰의 구조·수명·보안 리스크까지 이해하는지를 보고 있습니다.

이번 글에서는 JWT 인증 구조, Refresh Token 설계 이유, 그리고 실무 보안 적용 사례까지 정리했습니다.


📌 1. JWT(JSON Web Token) 기본 구조

JWT는 세 부분으로 구성된 문자열입니다.

xxxxx.yyyyy.zzzzz

구성 의미 설명

Header 토큰 메타정보 {"alg": "HS256", "typ": "JWT"}
Payload 사용자 데이터 {"userId": 123, "role": "admin"}
Signature 서명 검증 Header + Payload를 Secret Key로 서명

📌 JWT의 핵심:
서명(Signature)으로 위조 여부를 검증할 수 있어, 서버 세션 저장소 없이 인증 유지가 가능함.


📌 2. JWT 동작 흐름

  1. 사용자가 로그인 요청
  2. 서버가 사용자 인증 후 Access Token, Refresh Token 발급
  3. 클라이언트는 Access Token을 Authorization 헤더에 담아 요청
  4. Access Token 만료 시 Refresh Token으로 재발급 요청
sequenceDiagram
Client->>Server: 로그인 요청 (ID, PW)
Server-->>Client: JWT Access + Refresh Token 발급
Client->>Server: API 요청 (Authorization: Bearer Token)
Server-->>Client: 응답 (인증 성공)
Client->>Server: Access 만료 → Refresh로 재발급 요청

📌 3. Refresh Token을 사용하는 이유

구분 Access Token Refresh Token

유효기간 짧음 (15~30분) 김 (7일~30일)
저장 위치 메모리/쿠키 HttpOnly Cookie
역할 인증 요청 시 사용 Access 재발급용
보안 중요도 중간 매우 높음

📌 핵심:
Access Token이 탈취되어도, Refresh Token 없이는 장기 세션 유지 불가.


📌 4. JWT 보안 위험과 방지 전략

반응형

위험 설명 대응

탈취 브라우저 저장소(LocalStorage) 노출 HttpOnly Cookie 사용
위조 Secret Key 노출 시 변조 가능 비대칭키(RS256) 사용
만료 갱신 로직 누락 시 UX 저하 Refresh Token으로 재발급
무효화 불가 로그아웃 시 즉시 폐기 어려움 서버 블랙리스트 캐싱 (Redis 등)

📌 5. 실무 적용 사례 (React + NestJS)

상황:
JWT를 LocalStorage에 저장하던 기존 구조 → 브라우저 스니핑으로 탈취 위험 발견

개선:

  1. Access Token: 응답 헤더에 포함
  2. Refresh Token: HttpOnly + Secure + SameSite Cookie 설정
  3. /auth/refresh 엔드포인트로 자동 재발급
  4. Redis에 Refresh Token 블랙리스트 관리

코드 예시 (NestJS)

@Post("refresh")
refresh(@Req() req) {
  const refreshToken = req.cookies["refresh_token"];
  if (isBlacklisted(refreshToken)) throw new UnauthorizedException();
  return this.authService.reissueAccessToken(refreshToken);
}

📈 결과:

  • 탈취 사고 0건
  • 자동 토큰 갱신으로 UX 개선 (로그인 유지 7일)
  • Lighthouse Security Score 100점

📌 6. 압박면접 예상 질문 & 답변 포인트

  • Q. Refresh Token이 없다면 어떤 문제가 생기나요?
    → “Access Token이 만료될 때마다 로그인을 반복해야 하므로 UX가 저하되고,
    세션 만료 타이밍 제어가 어려워집니다.”
  • Q. JWT를 LocalStorage에 저장해도 되나요?
    → “보안상 권장되지 않습니다. XSS 공격으로 토큰이 탈취될 수 있으므로 HttpOnly Cookie가 안전합니다.”
  • Q. 로그아웃 시 토큰을 즉시 무효화할 수 있나요?
    → “기본적으로 불가능하지만, Refresh Token을 Redis 블랙리스트에 등록하여 강제 만료시킬 수 있습니다.”

📌 7. 면접에서 활용할 한 줄 정리

“JWT 기반 인증 구조에서 Access Token은 짧게, Refresh Token은 안전하게 관리합니다.
NestJS와 Redis를 이용해 블랙리스트 토큰 관리까지 구현해,
탈취 리스크를 줄이면서 UX도 개선했습니다.”



압박면접,JWT,RefreshToken,AccessToken,보안설계,HttpOnly,Redis,토큰인증,React,NestJS


 

※ 이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2026/04   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30
글 보관함
반응형