Session과 JWT 그리고 Cookie

정말 뜬금없지만 어릴적 자주 보던 만화 '스폰지밥'의 한 장면이다. 스폰지밥이 할머니댁에 방문해 우유에 쿠키를 찍어 먹는 장면이다. 이 장면을 볼때마다 참 맛있겠다 라는 상상을 하곤 했다. 뜬금없이 왜 먹는 쿠키 이야기를 할까??

 

인터넷에도 쿠키라는게 존재한다. 다음의 화면은 '마이크로소프트 엣지'라는 브라우저의 설정창에서 쿠키를 검색했을때 나타나는 화면이다. 주로 기록, 암호, 쿠키, 데이터 등이 연관이 되어있음을 알 수 있다.

인터넷에서 말하는 쿠키란 무엇일까?

 

일반적으로 쿠키를 사용하게 되면 서버에 있는.

우리가 쿠키를 사용하게 된다면 서버에 있는 브라우저에 데이터를 넣거나 수정할 수 있게 되며 이 속에는 인증을 포함한 다양한 정보(언어 설정, 도메인에 따른 유통기한 등)을 설정할 수 있게 된다.

 

즉 브라우저를 사용할 때마다 다음과 같은 과정이 일어나게 된다.

1. 먼저 사이트에 방문하게 되면 브라우저는 서버에 request를 보낸다.

2. 이때 서버는 response을 보내게 되는데

3. 이 응답에서는 해당되는 모든 데이터와 내가 찾고자 하는 페이지에 대한 정보가 기록되어있다.

4. 브라우저에 쿠키를 저장한 후 해당 웹 사이트에 방문할 때 마다 브라우저는 해당 쿠키도 요청과 함께 보낸다. 

 

 

이 즈음 자연스럽게 세션과 토큰이라는 단어가 나타나기 시작하는데 이 두가지가 왜 필요한지 알기 위해서는 Stateless라는 용어를 알 필요가 있다.

 

Stateless란?
서버로 가는 모든 요청이 이전 리퀘스트와 독립적으로 다루어 진다는 점이다. 즉 요청끼리의 연결(메모리)가 없다는 의미이다. 요청이 끝나면 서버는 누가 어떤 요청을 했는지 잊어버린다. 이렇기에 요청할 때마다 session을 사용해서 지속적으로 어떤 사람이 어떤 요청을 하는지 알려줘야 한다.

Session 세션
기본적으로 로그인을 하기 위해서는 구분을 하기 위한 ID와 password가 필요하다. 이것은 세션 DB에 사용자의 정보를 기록하며 해당 세션에는 별도의 ID가 있다. 이 세션 ID는 쿠키를 통해서 브라우져로 돌아오게 되며 저장이 된다. 즉 같은 웹 사이트의 다른 페이지로 이동을 하게 된다면 브라우저는 세션 ID를 가지고 있는 쿠키를 서버에 자동으로 보내게 되며 서버는 이것을 확인하게된다. (아직도 서버는 사용자가 누군지 모른다) 세션ID를 바탕으로 DB에서 확인한 결과 어떤 유저가 정보를 활용하는지 알게되며 이때 서버는 사용자가 어떤 사람인지 알게 된다. 이런 프로세스는 지속적으로 반복된다. 즉 로그인한 유저들의 모든 세션 ID를 DB에 저장해야하며 요청이 들어올 때마다 서버는 쿠키를 받아서 세션 ID를 확인하고 이 ID와 일치하는 유저를 찾아야한다. 그렇기에 유저가 늘어남에따라 DB가 늘어나는 이유이다. 

요약하자면 유저가 가지고 있는것은 단지 세션 ID일 뿐이며 쿠키는 이 세션 ID를 전달하기 위한 매개체 이다. 라고 정리할 수 있다.

 

인터넷 세상에서는 아쉽게도 모든것이 브라우저를 통해서 움직이는 것이 아닌 IOS, 안드로이드 등이 있다. 그렇기에 여기에서도 쿠키와 같은 개념을 활용할 필요가 있는데 여기서 나타난것이 토큰 이라는 개념이다.

 

토큰은 string과 같은 개념이라고 보면된다.
세션DB를 가질 필요도 없고 서버는 유저를 인증하기 위해 많은 노력을 할 필요가 없다. 토큰은 서버에서 받아서 요청할때마다 보내는것이다. 서버는 토큰을 밭은 후 조작 유무를 확인하기 위해 사인이 유요한지 확인을 하며 이 토큰이 유요하다면 서버는 이 토큰을 준 사람을 유저로 인증하게 된다.

JWT

DB를 늘린다는것은 지출이 늘어난다는 의미이고 이것을 방지하기 위해 JWT라는 개념이 탄생하게 되었다. 이것도 마찬가지로 토큰개념이다

 

JWT 예시 

asdf1561d65as1f6a1sg61qw6dg21as32df1g63d51q61wer3fg2as.a.ds0.0as3d5g13a5s1gfd.sad1g5asdfasd21f341f561w5aq6f1d321a.f1asd5f1351awq32f165sd1f63q1wdf

유저명 비밀번호를 서버에 보내고 이 다음에 이것이 맞다면 서버는 유저의 ID를 가져다가 사인 알고리즘을 이용해 '사인'을 하고 이 사인된 정보를 string으로 발송한다. 쿠키는 저장소에 제한이 있는데 JWT는 제한이 없기에 위의 예시처럼 길고도 긴 JWT를 만들 수 있는 것이다. 정리하자면 JWT는 DB에 자료를 저장하고 하는것이 아니라 DATA자체에 사인을 하고 그 사인된 Data를 전달하는것이 전부이다.


세션과 JWT의 차이

 

세션
세션은 단순히 세션 ID를 주기만 하면된다. 세션의 정보가 세션 DB에 있기 때문이다. 페이지를 요청하게 된다면 서버는 세션 ID를 DB에서 서칭해 배부하게 된다. 이렇기에 서버는 로그인된 모든 유저의 정보를 보관하고 있기에 특정 유저를 차단(벤)하거나 특정 유저만 접근 시키도록 할 수 있다. 단 이렇게 하기 위해서는 DB를 구매하고 이것을 유지해야한다. DB를 위해서 redis를 사용한다.

JWT
서버는 유저를 인증하는데 필요한 정보를 토큰에 저장하고 이 토큰을 준다.
페이지를 요청하면 서버는 해당 토큰이 유효한지 검증하기만 하면된다.
단 JWT는 암호화가 되어있지않다는 단점이 있어서 누구나 이 자료를 확인할 수 있다. 
서버는 단지 토큰의 유효성만 파악한다. 그렇기에 세션에서 사용할 수 있는 특정 유저 차단, 접근 등의 개념을 사용할 순 없다. 카톡의 QR가 대표적인 JWT와 같은 개념이다.

즉 규모가 작은 경우 JWT와 같은 것을 사용하다가 점점 더 커져서 전문적이며 보안 개념이 필요할 경우 세션으로 규모를 확장시키면 된다.