[TIL] 스프링 숙련 TIL - 26/04/14

오늘 할 일

공부한 내용

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 사용 흐름

  1. 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 다루기

문제 & 오류

내일 할 일