[Server] Session 과 JWT

🥕 Http 프로토콜에서는 클라이언트와 서버의 통신이 끝나자마자 상태정보를 잊어버린다 (Stateless)  따라서 통신을 할 때마다, 클라이언트의 정보를 요구한다.

 

이를 해결하기 위한 방법으로 인증을 하게된다.

 

로그인을 통해 사용자에게 권한을 부여하고, 인증을 통해 사용자의 권한을 확인하고, 반복되는 리소스 낭비를 피하게 된다.

 

인증에 자주 쓰이는 세션과 토큰을 비교한다.

 

 

 

---

 

 

 

 

😢  Session  :  유저 인증 성공 이후 서버에 세션 저장. 저장 후 response를 통해 유저의 쿠키에 세션 ID 가 저장되도록 한다. 유저 측에서 http를 요청할 떄에는 Session id 가 포함된 쿠키가 헤더에 포함되며, 서버는 Session id 및 Session Storage에서의 정보를 대조 후, 유저 및 로그인 정보를 식별한다. 

 

 

 

요청에도 쿠키가 있고,

 

응답에도 쿠키가 있다.

 

세션은 클라이언트에 따라 고유의 session ID를 부여한다. 따라서 서버는 세션 아이디를 통해 클라이언트를 구분한다.

세션 쿠키는 브라우저를 닫거나 서버에서 세션을 삭제했을 때 삭제가 되므로, 쿠키보다는 비교적 보안이 좋다. 

 

🦐 세션도 쿠키(쿠키는 저장 메커니즘이다.)를 사용한다. 하지만, 사용자의 정보가 저장되는 위치가 다르다.  

 

 

※ 쿠키는 클라이언트의 PC에 정보를 저장하고 Session은 웹 서버에 정보를 저장한다.

 

https://hahahoho5915.tistory.com/32

 

 

쿠키는 서버의 자원을 쓰지 않지만, 세션은 서버의 자원을 사용한다. 

 

쿠키?

---

쿠키를 클라이언트 로컬에 저장한다면,  변질 또는 request에서 스니핑 당할 우려가 있다.

 

 파일로 저장된다면, 브라우저를 종료해도 정보가 유지될 수 있다. 물론 만료기간을 따로 지정 할 수 있다.

 

 

 

→ 반면에 로컬 정보를 서버에 요청하므로 세션( 정보가 서벅에 있음 ) 에 비해 요청 속도가 빠르다는 장점은 있다.     따라서 적절한 상황에는 쿠키를 써서 서버 리소스관리에 도움이 될 수도 있다.

---

 

 

 

---

 

 

 

 

😒 JWT :  jason web token으로 header, payload, signature로 구성된다. 

 

https://jwt.io/

JWT.IO

 

 

json 형식의 토큰으로 payload에 키 , value 값으로 데이터를 저장하고, 만료시간도 지정가능 하며,  HS256 알고리즘과 signature 키를 조합해서 문자열을 만들어낸다. 

 

🤨 jwt의 핵심은 세션과 달리 서버가 아닌 클라이언트에 저장이 된다는 점이다. 

 

클라이언트에 저장이 되기 때문에, Session 보다 서버의 리소스를 덜 쓰게 되는 경우가 가능하다.

 

JWT가 세션보다 유리한 점은 서버의 메모리에 저장 공간을 확보 할 필요가 없다는 점이다. 클라이언트가 서버로부터 받은 JWT를 보관하고 있다가,  서버로 요청을 보낼때마다 헤더에 토큰을 실어서 보내면 된다. 

 

 

JWT 는 키 값에 의한 인증 처리가 가능하므로, Session과 달리 DB와의 통신을 생략 할 수 있다. 

    

 

• Session을 쓸 경우에는 접속 및 API의 사용 시, DB의 커넥션을 지속적으로 소모하게 되는 단점이 있는데,  다음 방식들로 일정 부분 해결이 가능하긴 하다. 
  • File Storage 방식
    • 서버의 특정 디렉토리로 파일 형식으로 세션이 저장 되는데, 로드 밸런싱을 해야 하는 상황에서 문제 발생.  단일 서버가 아닌 경우이기 때문에, 로드 밸런싱에서 기존의 세션이 사용하던 스토리지가 있는 서버로 세션을 항시 넘겨줘야 한다.
  • In Memory 방식
    • 서버가 죽는 경우, 로그인 유저가 많을 경우,  → 서버의 리소스를 쓰기 때문에 문제 발생.
  • 스케일 아웃 처리
    • DB가 나뉘어져 있고, 사용자의 접속이 어느 쪽 서버로 올 지 모른다면, Session을 사용하기 위한 추가 개발 리소스가 더 들어갈 수 있다.
    • 이는 특정 세션을 가지고 있는 경우 특정 세션에서만 통신하도록 하는 추가적인 기술이 필요 할 수 있다.

 

 

😒 JWT 의 단점 : 

• JWT 는 페이로드의 크기가 클수록 데이터 전송의 비용이 커진다. 
• 토큰이 탈취 당한 다면 만료 기간 까지 대처가 안되는 상황이 발생 할 수 있다. ( xss 공격에 취약) 
  
  • 때문에 만료일자를 짧게 잡아야 한다.

 

 

 

😐 JWT보다 Session이라면 ? 

• Session은 로그인 된 유저의 정보를 모두 저장하고 있어서, 유저에 대한 통제가 JWT보다 비교적 쉽다.
• JWT보다 데이터의 크기가 작다는 장점도 있다.
• 토큰이 탈취당할 경우 만료시까지 대처가 안되는 상황도 막을 수 있다.

 

 

상황에 따라 다르겠지만, 일반적으로 JWT를 더 많이 쓴다.

Session을 위한 서버 설정이나 추가 리소스 투입과 JWT를 통해 아낄 수있는 자원 이득이 더 크기 때문일 것이다.

 

 

 

 

 

물론 JWT가 만능이 아니다. JWT를 사용하는 것에 대한 단점과 위에 언급한 내용은 언제나 장점이기만 하지는 않다.

 

 

JWT에 대한 오해와, 세션으로 JWT(Json Web Token)을 사용하지 말자는 주장의 정리.

 

 

잘못된 내용은 지적 부탁드리겠습니다.