[보안] 쿠키-세션, JWT 토큰 인증

쿠키-세션, JWT 토큰 인증

쿠키-세션 인증과 JWT 토큰 인증을 알아보자.

쿠키-세션 인증

HTTP 프로토콜의 Stateless

HTTP 프로토콜은 클라이언트와 서버의 모든 연결을 저장해두면 메모리 부족, 서버의 분산 등 문제가 있을 수 있으므로 Stateless(비연결성, 무상태) 상태이다.
이 Stateless 상태에서 인증된 클라이언트임을 확인하기 위해서는 그 정보를 쿠키와 세션에 저장해야 된다.

쿠키-세션 인증의 과정

  • 클라이언트가 ID와 Password를 서버에게 보내준다.
    • 클라이언트 —(ID, PW)–> 서버
  • 서버는 해당 정보를 DB에서 조회하고 정확한 사용자의 정보라면 서버의 Session에 인증한 정보를 기록하고 sessionID를 쿠키로 발급하여 클라이언트에게 전달한다.
    • 클라이언트 <–(sessinID)– 서버
  • 쿠키는 발급받은 sessionID를 서버에게 보내 로그인 한 사용자임을 인증한다.
    • 클라이언트 –(sessinID)–> 서버 (인증 완료)

쿠키-세션 인증의 단점

  • 별도의 저장 공간이 필요
  • 탈취 당하면 악의적으로 사용 가능

두 단점을 뒤집기 위해서 JWT 토큰을 발급받아 사용할 수 있다.

캐시 vs 쿠키

  • 공통점은 둘 다 클라이언트에 대한 서비스
  • 캐시 : 자주 사용하는 정보 (영구적으로 저장됨)
  • 쿠키 : 만료 기간이 정해져있고 만료 기간 이후 삭제된다.

JWT 토큰

쿠키-세션 인증의 단점을 뒤집는 방법이 필요
-> JWT 토큰(Json Web Token)을 발급한다.

JWT 토큰의 구성 요소

  • header : 토큰 타입, 인코딩 방식
  • payLoad : 회원정보나 전달하고 싶은 정보 (디코딩 할 수 있으므로 민감한 정보는 넣지 않는다.)
    • iat(발급 시간), exp(만료시간) -> 계정 관련 정보는 만료 기간이 있다.
  • signature(서명) : 특정 서버에서 발급했다는 서명 (서버가 발급한 암호화에 들어가는 키가 있음)

signature에 사용되는 비밀키가 탈취당하면 JWT 토큰 인증도 위험하기 때문에 https 프로토콜로 보안을 강화해 주는 것이 좋다.

JWT 예시

1

(출처 : https://jwt.io)

{HEADER를 base64UrlEncode}.{PAYLOAD를 base64UrlEncode}.
{ {HEADER를 base64UrlEncode} + “.” + {PAYLOAD를 base64UrlEncode} +암호 키}를 HMACSHA256 방식으로 암호화한 값}

JWT 토큰 인증의 과정

  • 클라이언트가 ID와 Password를 서버에게 보내준다.
    • 클라이언트 —(ID, PW)–> 서버
  • 서버가 JWT 토큰을 발급( 클라이언트만 따로 저장, 서버는 따로 저장 X)
    • 클라이언트 <–(JWT 토큰)– 서버
  • 이후 로그인은 클라이언트가 헤더에 JWT 토큰을 보냄
    • 클라이언트 —(JWT 토큰)–> 서버
  • 서버에선 그 JWT 토큰을 확인해서 인증을 확인한다.
    • signature를 확인하여 본 서버에서 발급해 준 JWT 인지 확인 후 header와 payLoad을 디코딩함.
      • header와 payLoad를 인코딩한 값과 서버의 비밀키를 헤더에 있는 방식으로 암호화한 후 signature와 일치하는지 확인한다.

인코딩 : 복호화 할 수 있는 방식, 암호화 : 복호화 할 수 없는 방식 (인코딩 != 암호화)