세션, 쿠키, 토큰, JWT, 캐시

1. 쿠키

HTTP의 일종으로 사용자가 어떠한 웹 사이트를 방문할 경우,
그 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일

=> 클라이언트의 상태 정보를 클라이언트의 PC에 저장하였다가 필요시 정보를 참조하거나 재사용할 수 있다.

쿠키를 이용해서 서버는 나의 브라우저에 데이터를 넣을 수 있다. 

 

우리가 사이트에 방문하면 브라우저는 서버에 요청을 보내고, 서버는 이에 응답할텐데 응답에는 모든 데이터와 내가 찾던 페이지 정보가 있을텐데 그곳에서는 브라우저가 저장하고자 하는 쿠키가 있을 수 있다. 

 

해당 웹 사이트를 방문할 때마다 브라우저는 해당 쿠키도 요청과 함께 보낼 수 있다.

참고로, 쿠키는 도메인에 따라 제한되는데

유튜브가 준 쿠키는 유튜브에만 보낼 수 있다. 또한 쿠키는 유효기간이 있다.

이는 곧 서버가 정한 기간에 따라 유효하다. 

 

이러한 쿠키는 인증 뿐 아니라 여러가지 정보를 저장할 수 있다.

예를들어, 웹사이트 언어설저을 바꾸면 서버는 쿠키를 주고 내가 선택한 언어를 저장한다. (EN을 저장)

그렇다면 다음부터 내가 그 해당 웹 사이트를 방문할 때 EN이라는 정보가 담긴 쿠키는 요청과 함께 서버로 보내진다.

덕분에 서버는 쿠키가 기억해 둔 언어설정의 페이지를 제공한다.

 

 

2. 세션

http: stateless한데, 서버로 가는 모든 요청이 이전 request와 독립적으로 다뤄진다. 요청들끼리의 연결이 없고 메모리가 없다. 요청이 끝나면 서버는 보낸 브라우저가 누군지 잊어버린다. 그래서 우리가 누군지 request마다 알려주어야 하는데 그 중 하나가 바로 세션(session)이다. 

 

로그인을 해서 아이디와 비밀번호가 맞다면 서버는 세션 DB에 'Lulu'라는 유저를 생성하고 해당 세션에는 별도의 ID가 있는데 이 세션 ID는 쿠키를 통해 브라우저로 돌아오고 저장됨.

 

따라서 같은 웹사이트의 다른 페이지로 이동하면 브라우저는 세션 ID를 갖고 있는 쿠키를 서버에게 보낼 수 있다.

(위에서 언급했 듯, 쿠키는 자동으로 보내진다.)

서버는 들어오는 쿠키를 보고 세션 ID와 함께 오는 쿠키를 확인한다. 이때까지는 서버가 우리가 누군지 모른다. 

그저 세션 ID가 있는 쿠키를 지닌 요청이 있다는 것만 알 뿐이다. 

 

해당 세션 ID를 가지고 세션 DB를 확인할 것이고, 거기에서 유저 정보를 확인할 수 있다. 

 

유저에 대한 정보는 서버에만 있고 유저가 갖고 있는 것은 오직 세션 ID 뿐이다. 

쿠키는 그저 세션 ID를 전달하기 위한 매개체일뿐이다.

 

세션을 사용해서 ios, 안드로이드는 만들 수 있지만 쿠키를 통해서는 만들 수 없다. 쿠키는 브라우저에만 있기 때문이다.

쿠키는 네이티브 앱이 없다. 이 경우, 토큰을 사용한다.

 

3. 토큰

즉 서버에 '토큰'을 보내버린다. 토큰은 그냥 긴 string이다. 해당 토큰을 서버에 보내고 서버는 세션 DB에서 해당 토큰과 일치하는 유저를 찾는다.

세션을 이용한 토큰의 저장방식은

 

현재 로그인한 유저들의 모든 세션 ID를 DB에 저장하여, 요청이 들어올 때마다 서버는 쿠키를 받아서 세션 ID를 보고 

세션 ID와 일치하는 유저를 찾아야하고 그제서야 다음 작업을 수행한다. 즉, 요청이 있을 때마다 DB를 찾아야한다 

 

그러나 유저가 늘어남에 따라 DB리소스가 더 필요하다. 이때 JWT가 등장한다.

 

4. JWT 토큰

 

JWT는 토큰 형식으로 JWT로 유저 인증을 처리하면 세션 DB를 가질 필요가 없고 서버는 유저 인증한다고 많은 일을 하지 않아도 된다. 

로그인 예시를 통해 JWT와 세션의 차이점을 알아보면

유저 lulu가 로그인을 하려면 유저명, 비밀번호를 서버에 보낸다. 여기까지는 같은데

기존과 다르게 유저명, 비번이 맞다고 서버는 DB에 뭔가를 저장하지 않는다. 대신 서버는 유저의 ID를 가져다가 사인 알고리즘을 통해 사인을 한다. 그리고 사인된 정보를 string 형태로 보낸다.

jwt는 보통의 sesssion ID보다 훨씬 긴데 공간의 제약이 없어서 엄청 길어도 괜찮다.  

 

즉, DB를 건드리지 않고 정보를 사인하고 전달한다. 

서버에 요청을 보내려면, 세션 ID와 비슷하게 '사인된 정보'혹은 토큰을 서버에 보내야 한다.

서버는 토큰을 받으면, 해당 사인이 유효한지 체크하고 유효하다면 서버는 우리를 유저로 인증한다.

 

세션에서는 그냥 세션 ID만 주면 된다. 세션에 대한 모든 정보는 세션 DB에 저장되어있다. 

페이지를 요청하면 서버는 세션ID를 DB에서 찾으면 되는 것이다.

 

JWT에선 서버는 유저를 인증하는데 필요한 정보를 토큰에 저장한다. 그리고선 그 토큰을 브라우저에게 넘기고

페이지를 요청하면 서버는 해당 토큰이 유효한지만 검증하면 된다. DB를 거칠 필요 없이!

 

JWT는 암호화 되지 않았다.

암호화가 되었다면 아무도 읽을 수 없고 이해할 수 없다.

JWT의 경우 누구나 열어서 해당 컨텐츠를 볼 수 있다. 그래서 비밀번호를 JWT 안에 두진 않는다.

토큰을 사인하고 이를 통해 유효한지 검증한다는 것

 

5. Session vs JWT 토큰 장단점

세션의 장점은 서버는 로그인 된 유저의 모든 정보를 저장해 해당 정보를 이용하면 새로운 기능을 추가할 수 있음

ex) 특정 유저를 쫓아내고 싶을 때 세션을 삭제해버리면 됨. 혹은 인스타그램처럼 로그인된 모든 디바이스를 보여줄 때 원하지 않는 디바이스에서 강제로그아웃을 할 수 있다. 또한 넷플릭스처럼 현재 로그인을 몇 명이 했고 시청하는지도 알 수 있다. 

 

이 모든 기능이 가능한 것은 서버가 누가 로그인 했는지 저장했고, 세션DB가 있기 때문이다.

이것을 유지하려면 DB를 사고 유지를 해야한다. 게다가 유저가 늘어나면 늘어날수록 DB도 커져야한다.

 

이를 위한 DB로는 주로 Redis를 사용한다. 빠르고 저렴한 DB

 

JWT를 사용하면, 생성된 토큰을 추적하지 않는다. 서버가 아는 것은 토큰이 유효한가 여부이다.

DB를 사지 않아도 되지만 강제 로그아웃 같은 기능은 할 수 없다. 토큰이 만료되기 전까지는 유효하다.

 

JWT는 DB 없이 가능하다는 게 장정이다.

 

한국에서 코로나때문에 하는 QR 체크인은 바로 JWT가 들어간 QR코드이다.

그 중 하나가 세션이나 DB없이 유저 인증을 할 수 있다는 점에 있다.  

 

6. 캐시

캐시(Cache)는 웹 페이지 요소를 저장하기 위한 임시 저장소이고,

쿠키/세션은 정보를 저장하기 위해 사용된다.

캐시는 웹 페이지를 빠르게 렌더링 할 수 있도록 도와주고,

쿠키/세션은 사용자의 인증을 도와준다.

• 캐시는 이미지, 비디오, 오디오, css, js파일 등 데이터나 값을 미리 복사해 놓는 리소스 파일들의 임시 저장소이다.
• 저장 공간이 작고 비용이 비싼 대신 빠른 성능을 제공한다.
• 같은 웹 페이지에 접속할 때 사용자의 PC에서 로드하므로 서버를 거치지 않아도 된다.
• 이전에 사용된 데이터가 다시 사용될 가능성이 많으면 캐시 서버에 있는 데이터를 사용한다.
• 그래서 다시 사용될 확률이 있는 데이터들이 빠르게 접근할 수 있어진다. (페이지의 로딩 속도 ↑)