쿠키-세션, 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 예시

(출처 : 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와 일치하는지 확인한다.

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