Difference between cookies, session and tokens

so what are cookies and sessions to understand these concepts we need to get back to the basics let's take this example you want to login to your bank account you are provided with a logging screen where you can enter your username and password after you hit the login button your username and password go to your bank's server nowadays the logging procedure typically includes another verification step such as getting a text message but to make it more understandable i have simplified it next the server needs to verify that you are who you pretend to be so the bank server will check against the database to see if your credentials match if everything looks good the server will show your account overview page but there is more that is happening in the background once the server verifies your credentials it will also create an entry in the database with your login event and give you a session id in a form of a cookie in other words you have exchanged your username and password for this cookie containing the session id the session id is just a unique identifier for your logging session and it is randomly generated the concept is similar to giving your code at the cloakroom and receiving a ticket with a number i've explained the basics around cookies in another tutorial which i will link in the description you can check this login process for yourself on almost any website to better understand it in google chrome or any other browser you can open the developers tools and inspect your network traffic for example here i've sent my username and password and received a cookie with this session id the content of the cookie is secret and other websites cannot read it so the server will store the session information in the database and you will only have the session id in a cookie which is stored on your computer's file system next time you request another page your browser will automatically send a cookie containing your session id which the server will check to see if it is still valid it is essential to notice that the second time your username and password are no longer required in order to uniquely identify you if you log out your login session will be invalidated in the database but also the server will instruct the browser to delete the cookie containing the session id even so if the session on the server expires the cookie becomes worthless your session will expire if you are inactive for some time the bank server will keep the session active as long as you keep interacting with the server if for some time you are inactive and you want to visit a new page the server will notice this period of inactivity and will prompt you to provide your username and password again as a security measure some websites like facebook for example may create a long-lived session which means that you will rarely need to enter your login credentials however your bank may use a very short live session commonly 5 minutes or less if you are inactive for 5 minutes you need to log in again the concept of a cookie can be hard to grasp let me make an analogy think about a cookie like your gym membership card it stores your member id on it and when you scan it at the entry it checks if your membership is still valid and lets you in as with your gym card a cookie with a session id only works with a specific website you cannot use your gym card to enter your office building for example and also if your gym membership expires your card will become useless now let's go back to the login example this method is called a cookie-based authentication accordingly this authentication used a session on the server to handle this the cookie is only the medium used to transport the session id and it is used because it is convenient the browser will always send cookies with every request technically speaking cookies are sent using http headers in the messages exchanged between the browser often referred to as the client and the server http is the protocol that ensures that both the browser and the server can understand each other in this case the bank stores the session information on the server side and you cannot see the contents of it this also ensures that you cannot manipulate any information let's talk about this real quick one of the reasons why servers don't store more information in cookies is that they cannot be trusted as they come from the client this is a security concern it is like telling the bank i have 1 million dollars in my bank account just trust me this is why servers prefer to work with their database where ideally only valid information exists so to recap the session is generated by the server and will be stored in a database you as the client will only receive the id of that session often referred to as the session id the session id is a meaningless randomly generated and hard to guess sequence of letters and numbers cookies are used as a transport medium for the session id as browsers will automatically send any cookies associated with a website and finally as cookies can be modified by the client the server cannot trust them and always needs to validate them traditionally cookie-based authentication has worked very well for many years but it is slowly becoming outdated at least for some use cases let's now assume that you want to install an app on your phone which can help you with your finances and keep track of your spending what you don't want to do is to give your username and password to this app which is not created nor verified by your bank in this case your app will redirect you to your bank you will enter your username and password and your bank will ask hey john would you like to give this app access to your transactions and you will check yes and the app will receive a token granting access to your transactions this token is like a temporary password if you wish it is like when you are at a hotel and get a one-day wi-fi password however a token is a bit more than a password most of the time it will give limited access to your data in this case the app will only view transactions the app will not be allowed to perform money transfers or to see other details i am sure you have seen a procedure similar to this anytime you have used facebook google or microsoft to grant access to your user profile to a third party website so in this exchange you never expose your username and password apart from authenticating with the bank if you later want you can easily revoke access to your account by invalidating the token which is decoupled from your account password one of the most popular protocols used for such scenarios are oauth open id but also jwt which is pronounced jot let's take a look at how a token issued by the bank can look like let's use json web tokens or chart tokens as an example a jot token contains more than just a temporary password the bank may issue a token containing some important information such as the customer id the scope that this token grants when was the token created and when does it expire one important aspect to remember is that this information is cryptographically signed this means that it is easy to verify that the content has not been modified tampering with the content and generating a new signature is impossible unless you are the bank the app can use this token to go to the bank and get transaction data or any kind of data that the user has granted access to in this exchange the app does not know the password of the customer but it is still able to retrieve some data the example i have given is just one use case of many and there are various ways on how tokens can be deployed and used so how is this token different from a session stored in a cookie when using cookies there are only two parties involved you and the server when using tokens it is essential to notice that the interaction typically involves multiple parties that may not trust each other so you trust your bank with your bank logging details but you may not trust this app that you have found in the app store for these reasons tokens typically follow a standard to ensure interoperability while sessions are implemented as needed by the server without necessarily following a standard additionally some tokens tend not to need a session on the server at all in the case of chat tokens the token contains the session information nevertheless this is not a rule another difference is that the token has a limited lifetime and a new token needs to be generated once it expires a token can also grant access to only a subset of the data a particular user or entity has a traditional session based authentication will grant access to all the information available most of the time talkers are sent using the authorization http header and not as cookies which use the cookie http header the reason for this is that nowadays many interactions happen outside of browsers for example from apps on your phone and it simply does not make sense to use cookies for that both session-based and token-based approaches are widespread and typically they are used in parallel for example a session based approach is deployed when using the website but a token based approach may be preferred when using the app from the same service so it is essential to understand how both work i hope that this was useful and has helped you better understand the difference between cookies sessions and tokens in one of the upcoming tutorials i will show you how this is implemented in practice and how you can use postman to test such scenarios if you want to support me to make more videos like this one like and subscribe don't forget to leave a comment in the section below and i will see you next time

Channel: Valentin Despa

Views: 6,174

Keywords: difference between session and cookies, what is session, jwt authentication, authentication, security, sessions, cookies, localstorage, web storage, redis, token

Id: GhrvZ5nUWNg

Length: 11min 53sec (713 seconds)

Published: Thu Sep 02 2021