기술면접 - 실전

토큰 저장 정보

• JWT란 유저를 인증하고 식별하기 위한 토큰 기반 인증
• RESTful과 같은 무상태 환경에서 사용자 데이터 교환이 가능
• 토큰에는 헤더, 페이로드, 시그니처로 구성
  a.헤더 : 키, 타입(토큰 유형 JWT는 JWT), 암호화 알고리즘으로 구성
  b.페이로드 : 토큰에서 사용할 정보의 모음, 탈취를 고려해 민감 정보가 들어가서는 안됨(JWT는 인코딩 될 뿐 암호화되지 않음)
  c.시그니처 : 헤더에서 정의한 알고리즘 방식을 활용, 서버에서 관리

사용 이유

• 서버에 부하가 적음
• 서버가 클라이언트 상태를 저장하지 않아 확장에 용이
• 적절한 사용시 보안성이 좋음

토큰 저장 위치

• 토큰 관리에 사용되는 저장소는 일반적으로 로컬 스토리지/ 세션 스토리지/ 쿠키/ 비공개 변수(함수 스코프 안에서 동작하는 로컬 변수)가 존재

종류

• 쿠키 : 모든 요청에 쿠키가 전송되 성능 저하, HTTP Only(JS에서 쿠기 접근 불가), secure(HTTPS만 접근 가능), Samesite(쿠키를 발급한 서버에서만 사용 가능) 등의 옵션 필요
• 스토리지 : 네트워크 요청시 서버에 전송되지 않음
  a. 로컬 스토리지 : JS 코드를 통한 접근이 가능해 XSS에 취약하고 CSRF에 안전
  b. 세션 스토리지 : 로컬스토리지에 비해 제한적으로 텝에서만 유지
• 로컬 변수 : 새로고침시 로그인 유지가 안되어 재접속의 불편함 존재

Redis

• 현업에서 토큰 저장에 In-memory DB인 레디스를 사용
• 데이터의 유효기간 설정이 가능해 RDB 저장시 만료된 토큰 관리를 위해 DB에 접근하지 않아도 됨
• In-memory DB로서 RDB 보다 빠름

필터와 인터셉터 동작 과정

필터

• 서블릿 컨테이너에서 관리, Dispatcher Servlet에 전달전 수행
  a.올바른 전송 : HTTP 요청 -> WAS -> 필터 -> Dispatcher Servlet -> Controller
  b.전송 제한 : HTTP 요청 -> WAS -> 필터 -> 유효하지 못한 요청에 대한 응답 반환 (Dispatcher Servlet을 거치지 않고 필터 내에서 바로 반환 )

인터셉터

• 스프링 컨테이너에서 관리, Dispatcher Servlet을 거친 다음 수행
  a.올바른 전송 : HTTP 요청 -> WAS -> (필터) -> Dispatcher Servlet -> preHandle → Controller → 로직 수행 → postHandle → 응답
  b.전송 제한 : HTTP 요청 -> WAS -> (필터) -> Dispatcher Servlet -> preHandle → 결함 발견 → 응답