[TIL] 스프링 숙련 - JWT 인증 흐름

오늘 할 일

공부한 내용

JWT

JWT (Json Web Token)

JSON 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token

• 일반적으로 쿠키 저장소를 사용해 JWT를 저장함

JWT 사용 이유

1. 서버가 1대인 경우
   • Session1이 모든 Client의 로그인 정보를 소유함
2. 서버가 2대 이상인 경우
   • 서버의 대용량 트래픽 처리를 위해 서버 2대 이상 운영이 필요할 수 있음
   • Session 마다 다른 Client 로그인 정보를 가지고 있을 수 있음 ex) Session1: Client1, Client2 / Session2: Client3
   • 만약 Client1의 로그인 정보를 가지고 있지 않은 Server2나 Server3에 API 요청을 하게된다면
     • 해결 방법:
       1. Sticky Session: Client 마다 요청 Server 고정
       2. 세션 저장소 생성해 모든 세션을 저장
          • Session storage가 모든 Client의 로그인 정보를 소유하고 있기 때문에 모든 서버에서 모든 Client의 API 요청을 처리할 수 있음
3. JWT 사용
   • 로그인 정보를 Server에 저장하지 않고, Client에 로그인 정보를 JWT로 암호화하여 저장 -> JWT 통해 인증/인가
   • 모든 서버에서 동일한 Secret Key 소유
   • Secret Key 통한 암호화 / 위조 검증 (복호화 시)
   • 장점:
     • 동시 접속자가 많을 때 서버 측 부하 낮춤
     • Client, Server가 다른 도메인을 사용할 때 ex) 카카오 OAuth2 로그인 시 JWT Token 사용
   • 단점:
     • 구현 복잡도 증가
     • JWT에 담는 내용 커질수록 네트워크 비용 증가 (클라이언트 -> 서버)
     • 기 생성된 JWT를 일부만 만료시킬 방법 없음
     • Secret Key 유출 시 JWT 조작 가능
   • JWT 사용 흐름
4. Client가 username, password로 로그인 성공 시 a. 서버에서 ‘로그인 정보’ -> JWT 암호화 (Secret Key 사용) b. 서버에서 직접 쿠키 생성해 JWT를 담아 Client 응답에 전달
   • JWT 전달방법은 개발자가 정함

c. 브라우저 쿠키 저장소에 자동으로 JWT 저장됨   2. Client에서 JWT 통해 인증 방법
a. 서버에서 API 요청 시마다 쿠키에 포함된 JWT를 찾아서 사용
  
 - 쿠키에 담긴 정보가 여러 개일 수 있기 때문에, 그 중 이름이 JWT가 담긴 쿠키의 이름과 동일한지 확인하여 JWT를 가져옴
  
b. Server 
  - Client가 전달한 JWT 위조 여부 검증 (Secret Key 사용)
  - JWT 유효기간 지나지 않았는지 검증
  - 검증 성공 시,
    - JWT -> 에서 사용자 정보를 가져와 확인

JWT 다루기

문제 & 오류

내일 할 일