세션 vs 토큰 vs 쿠키? 기초개념 잡아드림. 10분 순삭! :: ChatGPT 정리

> English Summary

> English Full Text

 

[ 요약 ]

인증에 대한 이해를 돕기 위해 쿠키, 세션, 토큰, JWT에 대해 설명합니다.
쿠키는 서버가 브라우저에 데이터를 저장하기 위해 사용하는 방법이며, 요청 시 해당 쿠키를 서버로 보내줍니다.
세션과 토큰은 HTTP의 상태 비저장성을 보완하기 위해 사용됩니다.
세션은 서버 측에서 관리되는 데이터 구조이며, 서버 측에서 유효성이 유지됩니다.
반면, 토큰은 클라이언트 측에서 저장되는 데이터 구조입니다.
JWT는 토큰 기반 인증의 일종이며, JSON 객체를 사용하여 정보를 전송합니다.
적절한 인증 방법을 선택하고 구현하는 것이 풀스택 개발자로서 중요합니다.

서버에서 받는 토큰은 매우 이상한 텍스트로, 요청이 있을 때마다 전송해야 하는 매우 이상한 텍스트입니다.
로그인 후 JWT를 이용한 인증 방법을 설명하며, 서버에 요청을 할 때 해당 토큰 또는 서명된 정보를 서버에 전송하여 인증합니다.
서버는 서명이 유효한지 확인하여 토큰을 신뢰하고 우리가 누구인지 확인할 수 있습니다.
JWT는 세션을 사용하는 것보다 정보를 저장할 수 있는 용량이 크고, 세션 데이터베이스에서 검색할 필요가 없어 빠르게 인증을 할 수 있습니다.
하지만 JWT는 암호화되지 않아 누구나 JWT를 열고 그 안에 있는 콘텐츠를 볼 수 있으므로, 비밀 정보를 넣어서는 안 됩니다.

 

 

반응형

 

 

Sessions vs. Tokens vs. Cookies: The Basics. 10 minutes!
https://www.youtube.com/watch?v=tosLBcAX1vk 

 

 

[ 한글 전체 ]

안녕하세요, 니콜라스 입니다.
인증은 애플리케이션이 사용자가 누구인지 파악하는 방법이며결국 풀스택 커리어를 쌓아가는 과정에서 반드시 만들어야 하는 부분입니다.
인증을 구현해야 하는 경우 쿠키, 세션, 토큰 또는 JWT와 같은 단어를 보게 될 것입니다.
세션, 토큰 또는 JWT와 같은 단어를 보게 될 것입니다.
이들 간의 차이점이 혼란스러울 수 있기 때문입니다.
이 비디오에서는 이 단어들이 서로 어떻게 관련되어 있고 어떻게 작동하는지 살펴볼 것입니다.
이 동영상이 끝나면 모든 것이 무엇을 의미하는지, 언제 사용하는 것이 가장 좋은지 알 수 있을 것입니다.사용하세요.
이제 온라인에서 여러 번 본 질문과 제가 가졌던 질문부터 시작하겠습니다.쿠키와 토큰에 대한 질문입니다.
이 질문은 그 자체로 일종의 잘못된 질문이며, 제 생각에는쿠키가 실제로 어떻게 작동하는지 알지 못하기 때문입니다.
그럼 거기서부터 시작하겠습니다.
쿠키에 대해 이야기해 보겠습니다.쿠키는 서버가 사용자에 대한 정보를 기억하기 위해 브라우저에 데이터를 저장하는 방법입니다.
언제웹사이트로 이동하면 브라우저가 서버에 요청을 합니다.
그러면 서버는응답합니다.
응답에는 사용자가 원하는 페이지를 표시하는 데 필요한 모든 데이터와 코드가 포함되어 있습니다.
표시하는 데 필요한 모든 데이터와 코드가 포함되며, 서버는 해당 응답을 통해 브라우저에 쿠키를 저장할 수 있습니다.
이제부터는 브라우저에 쿠키가 저장된 후 해당 웹사이트로 이동할 때마다해당 웹사이트로 이동할 때마다 해당 요청에 따라 쿠키도 전송됩니다.
쿠키는 도메인에 따라 제한됩니다.
따라서 예를 들어, 유튜브닷컴에서 제공하는 모든 쿠키는 유튜브닷컴으로만 전송됩니다.
쿠키에는 만료일도 있습니다.
일부 쿠키는 하루, 일주일 또는 서버가 원하는 시점에 만료될 수 있습니다.서버가 원할 때마다 만료될 수 있습니다.
쿠키는 모든 종류의 것을 기억하는 데 사용될 수 있습니다.
쿠키는 실제로인증과 관련이 있습니다.
예를 들어 웹사이트의 언어를 변경하면 서버에서어떤 언어를 선택했는지 기억하는 쿠키를 제공할 수 있습니다.
그러면 다음에해당 웹사이트를 다시 방문하면 쿠키가 해당 요청과 함께 전송됩니다.
따라서 서버는원하는 언어로 페이지를 제공할 수 있습니다.
이제 세션과 토큰에 대해 이야기해 보겠습니다.
세션과 토큰이 필요한 이유를 이해하려면 웹사이트에 접속할 때 사용하는 프로토콜인 HTTP를 기억해야 합니다.
웹사이트에 접속할 때 사용하는 프로토콜인 HTTP는 상태 비저장형 프로토콜입니다.
상태 비저장성이란 서버로 전송되는 모든서버로 전송되는 모든 요청이 이전 요청과 독립적으로 처리된다는 것을 의미합니다.
요청 간에요청 간에 링크가 없습니다.
메모리가 없습니다.
요청이 완료되면 서버는사용자가 누구인지 잊어버립니다.
요청이 완료되면 서버는 우리가 누구인지에 대한 모든 것을 잊어버리므로서버는 요청이 완료되면 사용자에 대한 모든 정보를 잊어버리기 때문에 요청을 할 때마다 서버에 사용자가 누구인지 알려줘야 합니다.
이를 위한 한 가지 방법은세션을 사용하는 것입니다.
예를 들어 nico라는 사용자 이름이 있는데 로그인하고 싶다고 가정해 봅시다.
사용자 이름과 비밀번호를 서버로 전송합니다.
비밀번호가 맞으면서버는 nico 사용자에 대한 세션 데이터베이스에 레코드를 생성합니다.
해당 세션에는 고유한ID를 갖게 됩니다.
이 세션 ID는 쿠키를 전송 수단으로 사용하여 브라우저로 다시 전송되며쿠키를 사용하여 브라우저로 다시 전송되고 거기에 저장됩니다.
따라서 동일한 웹사이트의 다른 페이지로 이동할 때 브라우저는는 세션 ID가 있는 쿠키를 서버로 다시 전송합니다.
아시다시피 쿠키는는 자동으로 전송됩니다.
서버는 들어오는 쿠키를 살펴보고 다음을 수행합니다.세션 ID가 있는 쿠키가 들어오는 것을 확인합니다.
하지만 이 시점에서 서버는우리가 누구인지 알지 못합니다.
서버는 요청을 하는 사람이 있다는 것만 알고 있으며누군가 세션 ID가 있는 쿠키를 가지고 있다는 것만 알 수 있습니다.
서버는 해당 세션 ID를 사용하여 세션 데이터베이스에서세션 데이터베이스.
거기서 서버는 이 ID가 니코 사용자의 것임을 알게 되고, 그제서야서버는 우리가 누구인지 알게 됩니다.
그러면 서버는 다음과 같은 메시지를 표시할 수 있습니다.welcome nico.
그리고 다시 응답이 끝나면 모든 것이 완료되고 다른 페이지로 이동하면다른 페이지로 이동하면 전체 프로세스가 다시 진행됩니다.
여기서 기억해야 할 중요한 점은사용자에 대한 정보는 모두 서버 측 데이터베이스에 있다는 것입니다.
사용자에게는 오직세션 ID만 있습니다.
그게 다입니다.
보시다시피 쿠키는 데이터베이스에 있는 세션 ID를 주고받을 때 사용하는데이터베이스에 있는 세션 ID를 주고받는 데 사용하는 전송 방법일 뿐입니다.
세션을 계속 사용할 수 있습니다.세션을 사용할 수 있지만, 물론 쿠키는 네이티브 앱이 아닌 브라우저에만 존재하기 때문에브라우저에만 존재하기 때문입니다.
이러한 맥락에서 사람들은 이를 토큰이라고 부릅니다.
우리는토큰을 서버로 전송하지만 토큰은 문자열일 뿐입니다.
그냥 문자열일 뿐입니다.서버로 보내야 하고 서버는 그 토큰을 받아서그리고 세션 데이터베이스에서 해당 토큰을 가진 사람을 찾습니다.
세션에 대해 기억해야 할 가장 중요한 점은 서버가 로그인한 모든 사용자를 추적하기 위해 데이터베이스리소스를 사용하여 로그인한 모든 사용자를 추적해야 한다는 것입니다.
이는 또한 들어오는 모든요청이 들어올 때마다 서버는 쿠키를 가져와야 하고 세션 ID를 확인해야 합니다.
세션 ID에서 사용자를 검색해야만 계속 진행할 수 있습니다.
즉, 매번데이터베이스에 접속하거나 요청이 있을 때마다 세션 데이터베이스에 접속해야 합니다.
즉, 더 많은사용자가 로그인할수록 더 많은 데이터베이스 리소스가 필요합니다.
바로 이때 JWT를 소개합니다.
JWT는 토큰 형식이며 JWT를 사용하여 사용자를 인증하는 경우 세션데이터베이스가 필요하지 않으며 서버가 사용자를 인증하기 위해 그렇게 열심히 작업할 필요가 없습니다.
기억하세요,토큰은 서버에서 받는 매우 이상하게 생긴 텍스트로, 요청이 있을 때마다전송해야 하는 매우 이상하게 생긴 텍스트입니다.
JWT와 세션의 차이점을 살펴보겠습니다.로그인 예시를 다시 한 번 살펴보겠습니다.
사용자 이름이 nico이고 로그인하려면 사용자 이름과 비밀번호를 서버로 전송합니다.
이는 이전과 동일합니다.
사용자 이름과 비밀번호가 정확하다면,서버는 데이터베이스에 아무것도 생성하지 않습니다.
대신 서버는 사용자의 ID를 가져옵니다,를 가져와 서명 알고리즘을 사용하여 서명합니다.
그런 다음 서버는 서명된정보를 문자열로 전송합니다.
JWT의 모습은 다음과 같습니다.
보시다시피 매우 길며, 일반적인 세션 ID보다쿠키를 보낼 때 사용하는 평균 세션 ID보다 매우 깁니다.
이는 쿠키에공간 제한이 있기 때문이기도 합니다.
JWT에는 공간 제한이 없습니다.
매우 클 수 있습니다.
보시다시피 이전과 마찬가지로 로그인하지만이전처럼 로그인하지만, 서버는 데이터베이스에 접속하는 대신 몇 가지 정보에 서명하고서명하는 것뿐입니다.
이제 서버에 요청을 하려면 세션 ID를 사용할 때와 마찬가지로세션 ID를 사용할 때와 마찬가지로 서버에 요청하려면 해당 토큰 또는 서명된 정보를 서버에 전송하여 상기시켜야 합니다.
서버가 토큰을 받으면 서버는 서명이 유효한지 확인합니다.서명이 유효한지 확인합니다.
이는 기본적으로 아무도 토큰을 수정하지 않았음을 의미합니다.
서명이 유효하다면 서버는토큰을 신뢰하고 우리가 누구인지 확인할 수 있습니다.
바로 여기에 가장 큰 차이점이 있습니다.바로 여기에 가장 큰 차이가 있습니다.
세션을 사용하면 서버는세션 ID만 제공합니다.
세션과 사용자에 대한 모든 정보는 세션에 포함된 세션데이터베이스에 저장됩니다.
그리고 서버에 페이지를 요청하면 서버는 세션 데이터베이스에서 해당 세션 ID를 검색합니다.를 검색합니다.
JWT를 사용하면 서버는 사용자를 식별하는 데 필요한 정보를 토큰 자체에 저장합니다.
토큰 자체에 넣은 다음 우리에게 제공합니다.
페이지를 요청하면 서버는 서명을 확인하여서명을 확인하여 토큰을 수정하지 않았는지 확인합니다.
데이터베이스에서 검색할 필요가 없습니다.데이터베이스에서 검색할 필요가 없습니다.
또한 JWT는 암호화되지 않는다는 점에 유의하세요.
서명이 되어 있지만 암호화되지는 않습니다.
암호화됨는 아무도 콘텐츠를 볼 수 없음을 의미합니다.
아무도 무슨 일이 일어나고 있는지 이해할 수 없습니다.
JWT의 경우누구나 JWT를 열고 그 안에 있는 콘텐츠를 볼 수 있습니다.
따라서 JWT에비밀 정보를 넣어서는 안 됩니다.
다시 말씀드리지만 이것은 괜찮습니다.
요점은 정보를비밀로 하는 것이 아닙니다.
중요한 것은 토큰에 서명하고 아무도 토큰을 수정하지 않았는지 확인하는 것입니다.
그럼 이제세션으로 인증하는 것과 JWT로 인증하는 것의 장단점에 대해 이야기해 보겠습니다.
아시다시피 세션을 사용할 때 서버는 로그인한 모든 사람을 추적하여세션 데이터베이스.
세션 데이터베이스에 세션을 보유하면 애플리케이션에 필요한 기능을 구축할 수 있습니다.
기능을 구축할 수 있습니다.
예를 들어 강제 로그아웃이 필요한 경우, 사용자를 애플리케이션에서 내보내야 하는 경우애플리케이션에서 쫓아내야 하는 경우 데이터베이스에서 세션을 삭제하면 됩니다.
또는할 수 있습니다.
Instagram에서는 사용자가 로그인한 모든 디바이스 목록이 표시됩니다.
더 이상 인식하지 못하는 디바이스를 삭제하거나 강제 로그아웃할 수 있습니다.
또는 계정을 공유할 수 있는 사람의 수를 제한하고 현재 얼마나 많은 사람들이현재 로그인하여 시청 중인지도 알 수 있습니다.
이 모든 기능은 서버가 로그인한 사람을 추적하기 때문에 가능합니다.
추적하고 있기 때문에 가능합니다.
이러한 모든 기능은 세션 데이터베이스가 있기 때문에 가능합니다.
하지만 이 작업을 수행하려면, 애플리케이션에 로그인한 모든 사용자를 추적하려면추적하려면 데이터베이스가 있어야 합니다.
그리고 이 데이터베이스를 유지하려면유지해야 합니다.
그리고 비용을 지불해야 할 것이 하나 더 있습니다.
또한 사용자가 많을수록더 많은 데이터베이스가 필요합니다.
하지만 대부분의 사람들은 이 문제를 Redis를 사용하여 해결합니다.바로 이런 경우에 매우 저렴하고 빠른 데이터베이스입니다.
이제 JWT를 사용하면 서버는기본적으로 생성한 토큰을 추적하지 않습니다.
서버가 아는 것은 토큰이 유효한지 여부뿐입니다.유효한지 여부뿐입니다.
그게 다입니다.
JWT를 사용하면 추가 세션 데이터베이스에 대한 비용을 지불할 필요가 없습니다.
하지만 이는 곧 앞서 설명한 계정 기능을 구축할 수 없다는 뜻이기도 합니다.
다음을 할 수 없습니다.토큰이 만료되지 않은 한 유효하기 때문에 누군가를 강제로 퇴출시킬 수 없습니다.
그렇다고 JWT가 형편없다는 뜻은 아닙니다.
JWT는 실제로 꽤 좋은 기능입니다.
데이터에 서명하고 사용자에게 해당 데이터를 제공하는데이터를 사용자에게 제공하는 훌륭한 방법입니다.
그리고 데이터를 다시 받을 때 데이터가 수정되었는지 여부를 확인할 수 있습니다.
데이터가 수정되었는지 여부를 확인할 수 있습니다.
정말 멋진 기능입니다.
예를 들어, 한국에서는 카페나 레스토랑에 가서 체크인을 할 때 사용하는레스토랑에 체크인할 때 사용하는 이 애플리케이션은 실제로 QR코드에 인코딩된 JWT입니다.
따라서 JWT에는 다양한 사용 사례가 있습니다.그 중 하나는 세션 없이도 사용자를 인증하는 데 도움이 될 수 있습니다.데이터베이스.
그리고 우리가 찾을 수있는 한계와 한도를 알고있는 한 모두 좋습니다.찾을 수 있습니다.
저는 개인적으로 모든 애플리케이션을 JWT를 사용하여 시작하는데, 그 이유는 매우 간편하기 때문입니다.
구현하는 데 5분5분이면 됩니다.
하지만 애플리케이션이 성장하고 사용자 계정 시스템에 더 많은 권한이 필요하다고 생각되면 사용자 계정 시스템으로 넘어갈 것입니다.
이 동영상은 여기까지입니다.
이 영상을 통해새로운 것을 배웠기를 바라며 혼란스러우셨을 수도 있습니다.
이 동영상이 도움이 되셨나요?머릿속에 있는 내용을 정리하는 데 조금이나마 도움이 되었기를 바랍니다.
그럼요.
쿠키는 단지 전송 시스템일 뿐입니다.토큰은 서버가 기억하는 아주 이상한 문자열입니다.
그래서 서버로 보내야 합니다.서버가 신분증처럼 내가 누구인지 확인할 수 있도록 말이죠.
JWT는 토큰 시스템일 뿐입니다.데이터베이스 없이도 확인할 수 있는 자체 포함된 정보입니다.
때때로 트위터에서는JWT를 인증에 사용하기도 합니다.
때로는 세션을 사용할 수도 있습니다.
여기까지입니다.
감사합니다이 동영상을 시청해 주셔서 감사합니다.
궁금한 점이 있으면 댓글로 알려주세요.
다음 영상에서다음 영상에서 뵙겠습니다.
이 콘텐츠가 마음에 드시면 좋아요, 구독, 건강을 유지하는 것을 잊지 마세요,행복하세요, 김치를 드세요.
감사합니다.
사랑해요.
다음 영상에서 만나요.
안녕히 계세요.

 

 

SMALL

[ English Summary ]

To help you understand authentication, we'll discuss cookies, sessions, tokens, and JWTs.
Cookies are a method that servers use to store data in your browser, and you send them back to the server when you make a request.
Sessions and tokens are used to complement the statelessness of HTTP.
Sessions are data structures that are managed on the server side and are valid on the server side.
Tokens, on the other hand, are data structures that are stored on the client side.
JWTs are a type of token-based authentication, and they use JSON objects to transfer information.
As a full-stack developer, it's important to choose and implement the right authentication method.

The token you receive from the server is a very strange piece of text that must be sent every time a request is made.
We'll discuss how to authenticate using JWTs after login, and when you make a request to the server, you authenticate by sending that token, or signed information, to the server.
The server can verify that the signature is valid, so they can trust the token and verify who we are.
JWTs have a larger capacity to store information than using sessions, and they can authenticate quickly because they don't have to be searched in a session database.
However, JWTs are not encrypted and anyone can open them and see what's in them, so you shouldn't put secret information in them.

 

 

 

[ English Full Text ]

안녕하십니까, 니콜라스 입니다. Authentication is how your application knows who your users are
and is something that you are going to eventually have to make in your full-stack career.
If you ever need to implement authentication, you are going to see words like cookies,
sessions, tokens, or JWTs. Because the difference between them could be confusing,
on this video we are going to see how they are related to each other and how do they work,
so by the end of this video you will know what everything means and when is the best time to
use it. Now let's start with a question that I've seen many times online and a question that I had
before and that is cookies versus tokens. This question is in itself sort of wrong and I think
it comes from not actually knowing how cookies work. So let's start there. Let's talk about cookies.
Cookies are how a server can put data on your browser to remember something about you. When
you go to a website, your browser will make a request to a server. Their server will reply
with a response. The response will have all the data and the code required to show you the page
you are looking for and also on that response, the server can give to the browser some cookies
to save. From now on, after you get the cookies in your browser, every time that you go to that
website, the cookies are going to also be sent on that request. Cookies are limited by domain. So
for example, all the cookies that youtube.com will give you are only going to be sent to youtube.com.
Cookies also have an expiration date. Some of them can expire in a day, in a week or whenever the
server wants to. Cookies can be used to remember all sorts of things. They are not actually only
related to authentication. For example, if you change the language of your website, the server
can give you a cookie that will remember what language you chose. So then the next time that
you visit that website again, the cookie is going to go with that request. So the server will be able
to give you the page in the language that you want. Now let's talk about sessions and tokens.
To understand why we need sessions and tokens, we need to remember that HTTP, the protocol that
we use to go to a website, http youtube.com, that protocol is stateless. Stateless means that every
request that goes to the server is treated independently from the previous ones. There
is no link between requests. There is no memory. After the request is finished, the server will
forget about who you are. Because the server forgets everything about who we are once the request
is finished, we have to remind the server who we are with every request we make. One way to do this
is by using sessions. So if we have a username called nico, let's say, and we want to login,
we're going to send the username and the password to the server. If the password is correct, the
server will create a record in a sessions database for the nico user. That session will have a unique
ID. That session ID will be sent back to our browser using cookies as a transportation method
and there it will be saved. So when we navigate to another page on that same website, our browser
is going to send the cookie that has the session ID back to the server. Because as we know cookies
are sent automatically. The server is going to look at the cookies that are coming in and will
see that there is an incoming cookie with a session ID. Still, at this point, the server
doesn't know who we are. The server only knows that there is somebody making a request and that
somebody has a cookie with a session ID. With that session ID, the server will go and look on the
sessions database. There, the server will find that this ID belongs to nico user and only then
the server will know who we are. So then the server will be able to show us a message saying
welcome nico. And again, after the response is over, everything is finished and if we navigate to
another page, the whole process will happen again. The important thing to remember here is that all
the information about the user is on the server side is on the database. The user only has a
session ID. That's it. As you can see, the cookie is just the transportation method that we use to
send and receive the session ID that is on our database. We can still use sessions when making
iOS or Android applications, but we cannot use cookies, of course, because cookies only exist
on browsers, not on native apps. In this context, people will refer to this as a token. We would
be sending a token to the server, but the token is just a string. It's just a string that looks
really weird and that we have to send to the server and the server is going to take that token
and then is going to look in the session database for the person that has that token.
The most important thing to remember about sessions is that the server has to use database
resources to keep track of all the people that are logged in. That also means that with every
request that comes in, the server has to take the cookie, has to look at the session ID,
has to search the session ID for the user, and then it can continue. That means hitting the
database or hitting the session database every time there is a request. That means that the more
users are logged in, the more database resources we need. And this is when we introduce JWT. JWT
is a token format and if you use JWT to authenticate your users, there is no need to have a sessions
database and the server doesn't have to work that hard to authenticate a user. Remember,
a token is just a very weird looking text that we get from the server and that we have to send
on every request. Let's see the difference between JWT and sessions by looking at the
login example one more time. If we have a username nico and we want to login, we will send the username
and the password to the server. That is the same as before. If the username and password are correct,
the server won't create anything on the database. Instead, the server will take the ID of the user,
for example, and it will sign it using a signature algorithm. Then the server will send us the signed
information as a string. Here is how a JWT looks like. As you can see, it's very long, longer than
an average session ID that we use when we send cookies. This is also because cookies have a
space limit. JWTs don't have a space limit. They can be very big. So as you can see, we login just
like before, but instead of hitting the database, all the server is doing is signing some information
and giving that to us. Now, if we want to make a request to the server, just like when we were
using session IDs, we have to send that token or signed information to the server to remind the server
who we are. When the server receives our token, the server is going to check if the signature
is valid, which basically means that nobody modified the token. And if it is, then the server
will trust the token and you will see who we are. And that right there is the biggest difference
between making user authentication with sessions or with JWT. With sessions, the server just gives
us a session ID. All the information about the session and the user is contained on the sessions
database. And when we request a page to the server, the server will search for that session ID
on the sessions database. With JWT, the server will put the information needed to identify us
in the token itself and then give it to us. When we request a page, the server will just
verify the signature to see that we haven't modified the token. No need to search on the
database. Also, keep in mind that the JWT is not encrypted. It is signed but not encrypted. Encrypted
means that nobody can see the content. Nobody can understand what's going on. In the case of JWT,
anybody could open up the JWT and look at the content it has inside. So we shouldn't put any
secret information in the JWT. And again, this is okay. The point is not to keep the information
secret. The point is just to sign the token and verify that nobody has modified it. So now let's
talk about pros and cons between doing authentication with sessions and authentication with JWT.
As we know, when we use sessions, the server keeps track of all the people that are logged in on the
sessions database. Having the sessions in our sessions database allows us to build features
that applications need. For example, if you need to force a logout, if you need to kick a user
out of your application, you can just delete the session from the database. Or you can do what
Instagram does. In Instagram, they show you a list of all the devices that you have logged in from,
so you can delete or force logout of the devices that you don't recognize anymore.
Or Netflix that limits the amount of people that can share an account and also knows how many people
are currently logged in and watching. All these features are possible because the server is keeping
track of who is logged in. All these features are possible because we have a sessions database.
But remember, if we want to do this, if we want to keep track of all the people that are logged in
in our application, we have to have a database. And that is one more thing that you're going to
have to maintain. And one more thing that you're going to have to pay for. And also the more users
you get, the more databases you need. But most people solve this problem by using Redis, which is
a very cheap and fast database for exactly this kind of case. Now with JWT, the server doesn't
keep track of the tokens that it has created by default. All the server knows is if a token is
valid or not. That's it. With JWT, you don't have to pay for an extra sessions database,
but also that means that you cannot build those accounts features that we talk about. You cannot
force somebody out because their token is going to be valid as long as it hasn't expired.
This doesn't mean that JWT sucks. JWT is actually pretty good. It's a great way of signing data
and giving that data to the user. And then when receiving the data back, we can verify if the
data has been modified or not without having to need a database. That is a super cool feature.
For example, here in South Korea, this application that we use when we have to go to a cafe or a
restaurant to check in, this is actually a JWT encoded in a QR code. So JWT has many use cases.
One of them could be to help you authenticate your users without the need for a sessions
database. And that is all good as long as we are aware of the limits and the ceiling that we might
find. I personally start all my applications using JWT because it's so easy. It takes five
minutes to implement. But if the application grows and maybe I feel like I need some more power over
the user account system, then I will move on to sessions. And that's it for this video. I hope
that you learned something new and I hope that maybe we were confused. This video helped you a
little bit to organize what you have in your mind. Okay. Cookies are just a transportation system.
Tokens are just very weird strings that the server remembers. So you have to send that to the server
so the server can check who you are like an ID card. JWTs are just a token system that has
self-contained information that we can verify without the need for a database. Sometimes we're
going to use JWTs for authentication. Sometimes we're going to use sessions. That's it. Thank you
so much for watching this video. If you have any questions, let me know on the comments. I hope
I see you in the next one. If you like this content, don't forget to like, subscribe, stay healthy,
be happy, eat kimchi. 감사합니다. 사랑해요. See you on the next one. Bye bye.