jwt 정리

in Backend

기존 방식의 문제점

  • 기존 방식: 세션으로 사용자 인증 확인
  • 문제점:
    • 사용자가 많을 시 서버에 부하
    • 서버 부하로 인해 언젠가 재기동하게 되면 기존 로그인 정보가 사라져서 로그인이 풀림.
    • 서버 부하로 인해 서버를 여러 대 구축해놓고 그 앞에 로드 밸런서를 두면 특정 사용자의 a 요청은 server1로 가고, b 요청은 server2로 갈 수 있다. 그런데 이 때 로그인을 서버 1에서 해뒀다면, b 요청이 마침 로그인한 사용자만 접근 가능한 페이지일 경우 사용자 입장에선 로그인을 했지만 로그인을 하지 못한 것으로 처리되어 페이지를 볼 수 없게 된다.
    • 대안으로 sticky session이라 해서 한 번 서버 1에서 로그인한 사용자는 계속 서버 1에 요청하도록 할 수도 있지만, 근본적으로 서버에 부하를 주는 방식인 session을 사용하지 않는 것도 한 가지 대안이다. 그 것이 jwt다.

jwt

  • 로그인 인증 완료했다는 정보를 사용자의 요청 시 토큰과 함께 보낸다.
  • jwt 구성: header.payload.verify signature 부로 구성
    • header: 토큰 타입(jwt. 고정값), 암호화 방식 지정(ex HS256)
    • payload: json 형식으로 짜여진 사용자 권한의 범위, 토큰 발급자, 토큰 유효 일자 등의 정보(Claim)를 Base64로 인코딩하여 일련의 문자열로 만든다(쉽게 디코딩할 수 있으므로 여기까진 보안상 안전하다고 할 수 없다).
    • verify signature: header, payload, 서버가 갖고 있는 salt값을 지정된 암호화 방식으로 암호화하여 생성된 값.
  • 특징: stateless(시간에 따라 바뀌는 상태값을 가지지 않음. (vs session 방식: stateful)
  • 문제점: https 환경을 구축하지 않았을 시 header, payload, verify signiture가 담긴 jwt 정보가 통째로 유출될 수 있다. 개발 서버가 아닌 운영 서버에선 https 환경이 필수적으로 선구축되어 있어야 한다.

새로 깨달은 점

  • jwt가 서버에 부하를 주지 않기 위해 쓰이는 기술이라고만 알았지, 사실 jwt 방식 이전에 심플한 대안으로 서버를 여러 대를 구축하는 방법은 그것대로 문제가 있었고, 그 문제에 대한 해결책의 한계도 있어서 jwt를 쓴다는 것까지는 모르고 있었다.