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