이 포스트는 유튜브 채널 노마드 코더의 영상에 기반하였습니다.
Thanks to Nico, 구독과 좋아요👍
서비스가 유저를 구별하고 검증하기 위해서는 Authentication(인증)을 구현해야 합니다
(흔히, 로그인이라 불리는 그것)
이와 관련하여
쿠키, 세션, 토큰, JWT 같은 단어를 들어봤을 것입니다
이번 시간에는 이 단어들이 각각 무엇이며, 어떻게 연결되는지 알아봅시다👊
서버는 사용자의 정보를 기억하기 위해
사용자 브라우저의 쿠키라는 공간에 정보를 담습니다
사이트에 방문하면, 브라우저는 서버에 요청(request)을 보내게 되고 사용자가 찾던 페이지 정보를 응답(response)합니다
이 응답(response)에는 쿠키가 있을 수 있습니다
서버 -> 브라우저
쿠키가 한번 저장되면 브라우저는 서버로 다음 요청을 보낼 때 쿠키를 함께 보내게 됩니다
브라우저 -> 서버
(쿠키는 연관된 도메인 간에만 전송됩니다.
예로, 유튜브가 준 쿠키는 유튜브에만 보내집니다)
세션과 토큰이 왜 필요한지 이해하기 위해서는 먼저 HTTP가 stateless 프로토콜이라는 사실을 알아야 합니다
Stateless?
서버로 가는 모든 요청이 독립적으로 다뤄지는 특성으로, 과거의 요청을 기억하지 않습니다.
즉, 현재의 요청이 끝나면 서버는 사용자가 누구인지 잊어버릴 것입니다
따라서, 브라우저는 모든 요청에 사용자가 누구인지 알려야 하고, 이를 하는 방법 중 하나가 세션(Session)입니다
쿠키는 Session ID를 전달하는 매개체입니다
유저가 로그인하는 과정을 살펴봅시다
서버로 ID/PW 전달
Session DB에 유저 정보 생성
브라우저로 Session ID 전달
다음 요청부터 ID를 포함하여 전달
참고로, 안드로이드/iOS 네이티브 APP에는 쿠키가 없으므로 유저 인증을 위해 토큰을 사용합니다
JWT
세션의 문제점을 극복하기 위해 고안된 토큰을 이용한 방식입니다.
JWT를 사용하면, Session DB와 같은 리소스가 필요없게 되고 서버가 유저 인증에 많은 일을 하지 않아도 됩니다
토큰
서버가 기억하는 이상하게 생긴 텍스트라고 표현할 수 있겠습니다. hash값과 유사하게 생겼습니다
먼저 세션의 문제점을 알아보겠습니다
유저가 로그인에 성공하면 서버는 Session DB에 그 정보를 저장하고 ID를 발행해야 합니다
이로 인해 발생하는 2가지 문제가 있습니다
서버로 ID/PW 전달
Signed 정보 생성
브라우저로 토큰(Signed info) 전달
다음 요청부터 토큰(Signed info)을 포함하여 전달
참고로,
JWT에 의해 만들어진 토큰(Signed info)은 쿠키에 담기는 Session ID에 비해 훨씬 깁니다
쿠키에는 공간 제약이 있기 때문입니다
세션과 JWT를 사용했을 때 각각의 장.단점을 정리해보겠습니다