Authentication vs Authorization: Essential Guide for Backend Engineers

and finally my favorite topic which is authentication and authorization and this is probably one of those areas

which we encounter every day I'm pretty sure all of us have used authentication screens before you have we have logged

into different platforms you have signed up into different platforms those are basically called the authentication

flows and to summarize everything in two sentences uh authentication can be explained as something a mechanism to

assign an identity to a subject to say in the technical terms and basically to answer the question of who are you

authentication basically means who are you in a given context in a given context the context can be a platform a

operating system uh or your phone anything this the answer to this question the process of finding the

answer to the this question is called authentication in the same way the answer to this question which is what

can you do in that context in that platform in that operating system all your capabilities all your permissions

to say in the technical jargon those things the process of finding the answer of the question what can you do in a

particular context that process is called authorization those are the two sentence summaries of the whole topic

and this is what we are going to talk about in this video and we'll dive into different aspects uh different

components of authentication and authorization basically have a general high level and Technical understanding

of how it works what is the importance what are the different things that make up and build the whole authentication

and authorization flows and everything surrounding it now before we dive in let's have some historical context of

authentication so first we're going to start with authentication right and for

authentication let's have some historical context of what was the use of it how did we reach here and how did

we reach to the modern methods of authentication so the story start somewhere in pre-industrial societies

and here authentication was pretty intrinsic uh by that I mean it was implied so an identity of a person or a

subject was the same as the subject's recognition and what that means is someone someone who is already respected

in the community let's say a village Elder could vouch for a person and Deals whatever deals were made uh during those

times were sealed with a handshake uh an act of symbolizing Mutual recognition and agreement even though it was pretty

Elementary this method leveraged a form of auth authentication based on human contextual trust it was based on humans

right it was based on trust and that's how people started the initial methods of

authentication but as populations grew interactions extended Beyond uh familiar circles uh like Beyond this soci Beyond

this Village implicit trust mechanisms fail to scale this cannot scale right because this person who is this whoever

this is in the community the Elder Village Elder that guy is not trusted in all the communities in all over the

society in different different countries or continents right this method cannot scale so this marked the beginning of

his search for explicit authentication explicit o initially we said this was implicit o which is based on trust

people needed proofs of identity that could function independently of personal acquaintance independently of any person

and that led to that led to seals and cryptographic era so by the medieval period Society needed this is society

Society needed a system that scaled Beyond personal recognition which we talked about earlier just based on

people of trusted reputation who can vouch for other people or other subjects or other deals so Society needed a

system which is which can scale beyond that and during those times people came up with this system which is called a

seal it was Wax Seal people who have watched different movies or series of uh historical times you must have come

across this this is like some seal and this was know attached to different letters or different agreements as a

some form of authentication or you know some form of agreement and it was one form of early cryptographic mechanism a

seal uh which was of a unique pattern and this is put on documents uh which acted as signatures today we have

signature digital signatures and uh handwriting based signatures this was one kind of signature during the

medieval period and these seals function as the first widely adopted authentication tokens you can say these

were one kind of authentication tokens during those times and they were kind of a physical representations of identity

that relied on possession something you have if you have this seal you have this in your possession then you are said to

be authenticated and you can verify yourself using those seals seals had their vulnerabilities they were prone to

forgery uh marking the first recorded instan of authentication bypass attacks so we have in the modern times different

types of authentication attacks one of those kinds is a bypass attack a bypass attack basically means skipping the

authentication with malicious intents forging these kinds of seals for malicious intents was one kind of bypass

attacks during the medieval period and this led to the evolution of more sophisticated mechanisms uh including

things like uh water marks and encrypted codes right used in different trade documentation setting a foundation for

cryptographic thinking people started thinking more about codes how codes can evolve to prevent different kinds of

attacks and forgeries and frauds and that led to the next era which was past phrases and shared secrets so we can say

during the times of Industrial Revolution during the of Industrial Revolution a lot of progress

happened in terms of machines right in terms of machines a lot of progress happened and the whole world started to

change and at the same time at the same time communication systems also started to get upgrades

Communications systems also started to progress they started to evolve into more secure and more advanced form of

communications and during those times is technology called telegraph was introduced and Telegraph became a

critical infrastructure and with it came the need for secure message validation and operators whoever was operating

these telegraphs they used pre-agreed pass phrases you can say you can call it also password but there are some form of

pass phrases and that was an early form of shared secrets and these pass phases were the same as static passwords like

they are not dynamic they decided on one static string one static password and they used it as a pass among them and

that relied on the principle of we can say something you know earlier the principle

was something you possessed something you possessed which was a wax seal a some kind of token that you possessed

that you can show to verify yourself and that got evolved into something you know which is which is much better in terms

of security and that was one step into the evolution of which in the modern times you know as password that time it

was called P phrases and that that the principle whole principle of authentication changed into something

you know which is inside your brain or in some form of communication either written or verbal and after that we can

say we can skip all that to the modern times of computation computation computational architecture and all the

modern authentication that we know of and the first form of computation which you already know is main frames main

frames in the somewhere in mid 20th century and and authentication entered its first digital phase so in there is a

story called in 1961 researchers at mit's project Mac they were working with something called

compatible time sharing systems also known as ctss and they introduced the concept of passwords for multi-user

systems basically they were trying to come up with some kind of system which will allow multiple users to use a

computer without Shar sharing the data without sharing a users data between each other between each other and what

they did was they stored password in PL text which was in itself a very critical vulnerability and that came into view

when one of them printed the password file in plain text because you can it was a plain text file you can print the

password and that was the time when that vulnerability came into place and people got aware of that and this incident the

printing of the password file this incident marked the Genesis of secure password storage mechanisms right now we

have this philosophy that password should not be stored in plain text and this incident of someone printing the

password file in a printer that was the initial idea that motivated people to the philosophy of storing passwords

securely and that led to different Innovations like hashing that you use uh pretty pretty frequently today to store

passwords in our databases and different cryptographic algorithms which transformed passwords into irreversible

fixed length representations so hashing is basically cryptographically so you can say there is some kind of algorithm

it does some kind of computation you provide it a plain text uh string provid it and in turn it returns you a hashed

string a hash string basically means it has a computational algorithm it will transform that string the plain text

into a fixed length the length won't change it does not matter you provided a three character string or a 100

character string the length of the hash will stay the same depending on the hashing algorithm and it will provide

you the same result for the same string every time that was the promise of the hashing algorithm so these kinds of

algorithms started to emerge during in this era and authentication began to align with the principles of

confidentiality integrity and availability the core tenets of information security and then in the

1970s an explosion in in cryptographic research driven by the work of great people like Whitfield Dey and Martin

Helman the people who have come up with cryptographic algorithms their invention of the Diffy Helman key exchange

introduced the concept of asymmetric asymmetric cryptography enabling two parties to establish a shared secret

over a untrusted medium that was the first time asymmetric cryptographic technique asymmetric cryptography became

the backbone of modern authentication protocols all the protocols that we have now those are all based on asymmetric

key cryptography and you they are also called pki public Kee infrastructure systems and this era also gave the rise

to protocols like karos which introduced ticket based authentication and karos relied on trusted third parties to issue

tickets that verified both the user and service identity which is a precursor to token based authentication system that

we have now and we will shortly look at those token based authentication methods right now we are just exploring how all

the dots connect together how the historical context led to what we have today led to what we use used today all

the different algorithms mechanisms methods and standard practices moving on if we go forward during around

1990s when the internet was growing a need for scalable scalable authentication methods was also Rising

simple username and password based systems were not enough and they were not strong enough against brute force

and dictionary attacks that are new newly coming during those times and that led to something called that we have MFA

which is multiactor authentication so MFA came with the idea of a combination of different principles

it combined let's say three things one thing is something you know with something you have with something you

are basically something you know can be passwords or passwords or pins something you have can be cards smart cards or OTB

generators right and something you are that is your personal identification it can be biometric data biometric data

like fingerprints or retina scans right and MF came with this revolution of combining different principles different

level layers of principles that provide a combined security to all kinds of authentication applications and because

of that biometric authentication emerged as a groundbreaking development leveraging pattern recognition

algorithms and statistical models to identify users based on unique physical traits however biometric systems

introduce challenges of false positives negatives and uh template security so that is also not enough biometric

security was not the on step solution for all the problems that were emerging during those times and after that you

can say we are finally into the modern times modern times we can which we can Call 21st century the time that we live

today and in the 21st century the rise of things like cloud computing and mobile devices and API based

architectures they demanded Advanced authentication Frameworks none of the above authentication methods or

Frameworks or principles were enough so we needed more advanced more technically robust implementations of authentication

and during and because of those Demands a lot of different authentication components or authentication techniques

emerged and among those we can say some of the important things are o o o 2 these are the ones that we still use

today and these are the most popular ones these are I'm just talking about the different comp components of

authentication that we are going to discuss soon another thing is jwt's then we have zero trust

architecture we also have for passwordless passwordless authentication system like uh web authentication

eliminate passwords entirely relying on public key and private key stored in Hardware devices we'll discuss O2 n JWT

shortly and then this and this is the time that we live now and this is what the future looks like as of now during

the time I record this video we have a couple of candidates for the future of authentication world we have

decentralized identity decentralized identity that that is created using popular Technologies like blockchain

they they offer a they offer a lot of features robust features for authentication people are still they are

still in early stages now and people are still experimenting they are promising and a potential candidate

for future of authentication then the second is behavioral Biometrics we have this concept called

post Quantum cryptography so post Quantum cryptography is basically the idea that once quantum computers start

getting used heavily they are going to break all the cryptographic algorithms that we have now that provide the sense

of security that we have that our data our passwords our sensitive data is secure because of these algorithms we

have RSA and um different different types of public key private key algorithms that are very difficult to

break with the hardware with the computation capability of systems that we possess today so once quantum

computers get uh used heavily uh once they get common enough all these algorithms cryptographic algorithms they

are going to break because quantum computers are very very very fast in terms of what you have today and these

algorithms are not made for that this concept called post Quantum uh cryptography is basically cryptographic

techniques that are even secure for quantum computers we already have some algorithms as of my knowledge and you

can read up on that all in all this is pretty much all the historical context that we have of authentication in our

knowledge with that let's move on to the technical part the interesting part that you as a backend engineer should have

the knowledge of before I jump into authentication I want to introduce three components that we are going to discuss

again and again uh in this whole video so I feel it's better to introduce them right now before we start anything so

that you have some kind of context or some kind of familiarity when you hear them and these three are very important

in all the authentication on authorization flows though they are sessions J WTS

cookies and we'll discuss what are they let's start with sessions when the web started when the whole internet game

started HTTP protocol that we have that we use for our client server communication if

you have watched my HTTP video then you'll understand what I'm talking about HTTP emerged as the backbone of all the

commun communications between client and servers and by Design by Design sttp was stateless stateless stateless which

basically means HTTP treated every request as an isolated interaction so it did not remember what was what was your

previous request every request had enough and all the information that the server needed to perform the business

logic that's what it basically means for a stateless protocol it has it had or it has no memory of any past exchanges and

this was enough and this was ideal even for the earlier web the web that we started with which mostly consisted of

static Pages static images and data that people mostly read about just you look at a website you read something and you

move on rable data static data that we can call and people did not need continuity people did not need memory

between different requests that was not a need when it was designed however however when we evolved as the

web transitioned into Dynamic content and it happened very soon and when it evolved into Dynamic content the

statelessness statelessness of HTTP became a bottleneck how because we had different types of websites a highly

interactive websites websites like e-commerce sites which need to remember what are the items in your cart that is

one example of the interaction or How could a user remain logged in while navigating between different pages that

was another uh need and these questions marked the beginning of stateful interactions in the web stateful

interactions it was the need for stateful interactions otherwise modern websites modern needs of Technology was

not uh met that's why we needed the web to be stateful which HTTP was not and that's why the concept of session came

into play a session basically provided a way to establish temporary server side context for each user and it has some

kind of memory about the user that the server can have to remember the user when the user makes a request next time

so how did it work first part was session creation when a user logged in the server created a unique session ID

and it stored it along alongside the relevant user data whatever the users's role name whatever the data the server

needed uh to do different kinds of operation again and again it stored it with the session ID whatever the cart

items of the user is all those information that the server needed repeatedly it stored it in a persistent

store it can be a database or it can be a redis store which is a inmemory uh persistent store compared to database

which is a file based persistent store so the server stored the session ID with all the user data the cart items or

whether the user is authenticated or not all these different kinds of information with the session ID is stored in some

kind of persistent store and the second phase is the session ID this key unique key

was sent to the client which is a browser the server is somewhere in the remote it's it is somewhere in the cloud

and the session ID is sent to the user which on a browser as a cookie we will see what a cookie is but it is sent to

the user as a cookie and all the requests and all the requests that the client made after that after the session

being created included that cookie with those requests so that the cookie can have the session ID and using this

session ID server can fetch this information all the cart items users data from this persistent store it can

be redes or itav so basically this session IDE enable the web to have some kind of memory enable the servers to

have some kind of memory for the sake of the user for the sake of the client and in the third phase you can say these

sessions were short lift which means they had an expired date so let's say if the session's expired date is 15 minutes

so after 15 minutes the user sends this session ID to the server and they are expired so the server creates another

session and sends the session ID stores the user data in the persistance store and that's how it works again and again

that's how this whole session thing works and initially initially sessions started with file based sessions those

were the early session implementations and that stored data in files on the server even though they were simple that

approach suffered from scality issues as the number of users grew and server started to implements implement database

packed sessions to handle large user bases and to make the server scalable sessions data moved to databases which

provided faster lookups and persistent storage across server restarts that data stored in the databases and even though

the server restarted the session became available the session stayed available to the server and eventually we remove

we move to distributed architectures and during this era the session storage the persistent Store where the servers

stored the sessions and the users information move to distributed storage distributed storage like that we have

redis which is a inmemory store inmemory store basically means storing data in Ram compared to hard disk that's a on

line explanation or mcast which is also another in memory store and servers started to use these these were

comparatively faster as compared to DB lookups because they were in memory stores so that's how of the uh storage

evolution of sessions happened and we still use sessions even today for the same purpose to provide some kind of

memory to our servers moving on then we have is jws and this is a very popular technology in the current times these

are very popular and we will see why they become popular what are the advantages that they offered as compared

to our traditional session based uh authentication approach what are the additional benefits of using jts that

cause their popularity so continuing our earlier session discussion by the mid 2000s by the mid 2000s web applications

grown into globally distributed systems and stateful systems stateful systems even though they were effective they

caused a bottle link because first thing memory maintaining session data for millions of users became costly so we

right now we are talking about what led to the emergence of gilies so first thing is retaining session data for

thousands and millions and billions of users became a large overhead for a lot of servers second thing is

replication what this means is in distributed architectures synchronizing session data across servers or regions

one server could be in one part of the World another server could be in the opposite part of the world so

synchronizing the user data across these servers from different regions introduce latency so the authentication flow

introduced latency which is basically means delays in authenticating the user and consistency challenges because of

the synchronizing need and that led to the birth of gwts

JWT because developers sought a solution that could offload state from the server while maintaining security and integrity

that's what people came up with jws jws which were formalized in the 2015 were a stateless mechanism

stateless this is the word to focus on stateless there is stateless mechanism for transferring claims we'll see what

claims are shortly transferring claims in a stateless manner between different parties let's say two systems

transfering claims in a stateless manner between two parties or two systems and the key Innovation here was

selfcontained JWT s selfcontained tokens JWT tokens contain user data stuff like user ID their role

and the cryptographic signatures in one token which are base 64 encoded if we go to the website called JWT doio

we can take a look at what a JT looks like okay so this is what a JWT looks like this is the whole base 64 encoded

JWT string and JWT has three parts so to get a high level idea we can look at the parts which are first part is the header

the header basically specifies metadata metadata such as the signing algorithm which can help uh the server to get some

information on what was the signing algorithm that is used while the J was being created so the first part the

header basically contains metadata about the JWT itself stuff like the signing algorithm and the second part which is

the payload data the data of the user the data that we store in the JWT the data that we actually need this also has

some kind of format that we typically follow so the first thing is Sub sub is the field where we usually store the

users ID we store the user ID and the user ID can be in any context it can be user ID uh from your database it can be

user ID from an au provider it can be any user ID from any context this is just a storage mechanism right you store

the user ID of the user in the sub field in the IAT field this stores when the JWT was issued that is the information

the I field stores which means basically means issued at that's the full form of IAT and then we have optional Fields you

can store the name of the user and the role of the user whether the user is an admin is a member or it is a role of

editor or a viewer or writer whatever the role is you can store information like like that different kinds of

information in different kinds of fields inside the payload this is the part where you can store information and the

last part is the signature of the JWT to verify that whether you are the one who issued it whether this data has been

tampered or not right and you can do that with a secret key that you can generate and keepy for yourself only you

have an access to it if someone makes any change to the JWT and you verify that JWT with your secret key then the

validation will fail because someone made some changes to the JWT and it is not tamper proof anymore and now you

know that so that is not a JWT valid JWT anymore that's how you can verify users data in in a stateless manner now you

don't have to store the session information anymore whole session verification mechanism just became

stateless it it happens with every request it is very lightweight and saves a lot of storage cost so these are the

advantages that jws offered that made a lot of things in the authentication workflows very simple the first thing

was statelessness which basically enabled no server side storage costs second thing

was scalability scalability scalability basically means a lot of servers these days use the

microservice architecture and distributed architecture and which means a cookie issued from one server cannot

be used for a server which is in another domain as a in a microservice architecture so using technology such as

JWT enabled a client to send the JWT to different different servers and all the servers will have the secret key of the

JWT using which they can decode the jwd and verify the users's identity for now a lot of servers a server can be scaled

to a lot of instances and they won't have to worry about user authentication anymore all the servers can do the user

authentication at the same time using a shared secret key and that was one of the major benefits of gwts which and the

third thing is the portability and because because of the lightweight nature because of the URL friendly

nature because of the base 64 encoding string format jwt's could be passed between different systems they could be

stored in local storage even though you should not do that they should they could be stored in cookies and a lot of

different Limited Space storage systems they're very portable you can send them in url values and a lot of other

advantages that JWT is offered in terms of portability and on top of that they also introduced some challenges One

Challenge was token the the of token since JWT was stateless it was stateless there was no stored mechanism that the

server used to uh validate the user's identity if someone has access to your JWT now they can impersonate as you they

can use your JWT to perform actions on behalf of you that is the one disadvantage of gwts and there is no

mechanism from the side to invalidate that token until it expired manually unless unless the server changed its

secret the secret using which the server verified all the users now the problem with that is if the server changes the

secret to invalidate one token now all the users of that platform of that system will have to login again and get

new jws just because the server wanted to in validate token of one user that was one thing second thing was

revocation so for some reason if the server wanted to to revoke some users access or some users uh access to the

platform or access uh in different systems the server could not do that because jws since they are stateless you

have no way to track the status of a JWT token until they are expired you cannot really do anything so these are the two

major dis advantages that came up because of jts because of the use of jws even though these days we found some

kind of solution for that for example for the first thing and the second thing together we use a hybrid approach of

using gwts so using a hybrid approach again raises some questions first I'll tell you what a hybrid approach is which

he came up with to beat the above two advantages so this is how it works the user logs in and the server sends it a

token a JWT token which the user stores in its system okay and with every subsequent request to the server the

user sends a JWT in either a authorization header or in any other form or a quicky or anything okay and

that's how the server gets the JWT it verifies the JWT with its secret key and make sure the user has proper uh access

or it can identify the user that's how it works in a JW based workflow so in the hybrid approach

what we do is we combine statelessness with statefulness what that means is in a jwd typical workflow we don't make an

additional lookup in our storage the storage could be a database lookup or a inmemory lookup like redis or mcash we

don't do that we verify the JWT with a secret key and we find out who the user is using the user ID that is stored

inside the J WT that's it we don't do any additional storage lookup now in the hybrid approach what happens after you

verify the gwts after you uh have the verification step passed you maintain a blacklist of gwts in your persistance

storage again it could be a database call or a inmemory call for redis or mcast and using that you can temporarily

block some users revoke access for some users uh in case of some users account being hacked or some user doing some

malicious activity you can temporarily block their access using a blacklist now the question it raises is the whole

point of using JWT was the statelessness and if you are doing a persistent storage lookup for checking the validity

of the jwd why not do the statefulness why not do the stateful approach in the first place which can provide this

advantage and it is considered more secure so these are the kinds of questions that we frequently see uh in

the industry typically the advice is don't think about all these different authentication strategies and all go

with a Au provider we have a lot of different different types of authentication providers we have ozero

we have the modern Alternatives like Clerk and all that's their headache that's their headache to worry about

what technologies what components of authentication to use which is more secure which is a more secure way which

are more secure techniques and everything the starting from the algorithm to Hash to salt all the

different parts all the different headaches of authentication which which creates a secure authentication system

that's their headache it's very important if you are building a medium to a largly complex system it's a good

idea to go with an external o provider even though it's it's a good idea if you're learning backend engineering to

implement your own o understand how the different parts work and understand the tradeoffs understand the advantages and

disadvantages everything after that in a production system go with au provider go with an O provider unless you're very

confident about your authentication workflows okay that is my two sents about what you should do with all this

confusion about what is right what is not and all and the third thing that we have is Cookie and we have already

discussed and talked about using cookies in in the earlier two examples for example in the session based

authentication uh first I'll explain what a cookie is Cookie is basically some way of storing a piece of

information it can be any string any value it is one way of storing this information in a user's browser from the

server side that is the important part using cookies using cookies servers now can store some information in client

browsers from this side so this is a very nice features uh offered by browsers so using the HTTP request

workflow a servers can store some kind of information in the users browser given given certain conditions

conditions that that cookie is only accessible to that server a server cannot see other servers cookies so that

is a nice feature that is a nice security feature offered by the browsers so using this whole mechanism cookies

and all a cookie set by one server in a client's browser will be sent in all the subsequent request to that server so

this whole Workplay of cookies the server storing the cookie in the users browser and the cookie being sent to the

server with every subsequent request from the users browser this whole Workplay enables that during the

authentication workflow so let's come here during the authentication workflow first a user a client authenticates with

username and password to the server to the server and if the authentication is successful the server sets a cookie we

can say a cookie with the authorization token this looks something like V A JWT token or a session ID it can be whatever

depends on the implementation it stores it in the client's cookies and in subsequent request the client's browser

it can be Chrome Firefox Papa whatever it is tends this information this cookie key to the server so that the server can

validate authenticity of the token and it can authorize it can it can identify the user and it can authorize the user

and do all the uh workflows that comes after the authentication so cookie is a very nice way to automate the process of

server uh sending the token to the client and the client sending the token back to the server with every subsequent

request all of this can be done from the server side using the mechanism called cookies because the server has access

access to client cookies that is stored in the browser from the server side that is the part to focus on and that was

about three major components of modern authentication now let's move on to different types of authentication types

we pretty much already have discussed what are the two major types of authentication but here we can keep that

as a topic at hand and discuss them at a very high level the first part is stateful authentication and the

second is stateless we have also other methods of authentication we have API key based authentication we also have o

2.0 based authentication and these are pretty much all the major types of authentication that I can think of that

we use as backend engineers in our day-to-day lives okay let's dive into each of these types and see how they

work and what are the advantages disadvantages and when should you use which one and

everything about them pretty much okay let's get into stateful authentication first one is a stateful okay all in all

this is what stateful authentication typically looks like okay we have client here it is a browser let's say it is a

browser it's a chrome we have the client here client and we have the server here okay first step

during authentication the client sends username and password to the server username or password or email or

password whatever the authentication mechanism is to the server the server checks the validity and the correctness

of the password and the username on the email and all if they are correct if the user is eligible to authenticate into

the platform the server generates a session ID we have talked about sessions already and this workflow also already

but let's just discuss it again a session ID and the users data whatever it is and bundle s user data bundles

them and stores in redis it can be a database also but mostly platforms use redis because of the fast read time Fast

Access time of the redis as compared to our traditional databases okay and it stores in the redis and it sends the

session ID back to the client back to the client in a cookie in a cookie stores it inside a cookie a HTTP only

cookie which means JavaScript cannot access the cookie JavaScript cannot access the value of the session ID and

the server sends the session ID to the client back in a cookie and because of the nature of the cookie because of the

nature of the subsequent request attachment quality of the cookie what happens is all the request that happen

after that one will have this cookie where where the session ID is present and the server will get this cookie the

server will take that session ID and it will check the existence of that session ID in redis the expiry of that and the

user data and everything and it can identify the user it can authorize the user or whatever it wants to do and the

user can has the ability to call the API that's how the typical stateful authentication workflow works and the

session ID can be any cryptographic random string it can be JWT token whatever it depends on the

implementation and that's all about stateful authentication moving on to stateless authentication that's

stateless and this is how stateless authentication works we have a client again we it's a browser and we have a

server the user sends the username or password the email and password and password in the first request while the

user is trying to login the server checks the authenticity of the username and password and if they are correct if

they are correct the server generates a signed JWT token sign JWT token with a secret key the server has its own secret

key using which it can sign gwts and it can verify gwts this is very important it has to be stored somewhere securely

so that it can sign or verify jws and the server creates a new JW token which has the users information things like

user ID user role Etc and it sends the JWT back to the client okay then in all the next requests if the client wants to

identify itself it wants to authorize itself what it can do is it can send the JWT back in a header you can send in any

way but the standard is you can send in a header called authorization and you paste the jwd here

and you send it to the server the server extracts this token and it tries to verify it using the secret key that it

has and it verifies it and then it can find out the user's ID and if the verification is successful the

authentication is successful and the user can uh have a successful API response otherwise the Ser will throw an

error called unauthorized or forbidden or whatever the convention is and that's how a stateless Authentication works

because because it's called stateless because in a stateful authentication we need to look up a persistent store it

can be a database or it can be red and in a stateless authentication whatever information that we need about the user

is stored in the token itself in the JWT token itself which is a signed token which is a signed token and to verify

the authenticity of the token we have a secret key so it's a self sustainable self containing token which has the

users information that's why it's called a stateless token or a stateless method of authentication now when should you

choose which one so to answer that you have to understand the pros and cons of both the different uh kinds of

authentication mechanisms in a stateful authentication system the pros are you have the pros

are first you have centralized control you have centralized control control over all the sessions you have real time

information of all the active sessions of your users right because you have a persistent store to verify to get that

kind of information and using that you can easily revoke access of a user you can revoke a session you can log out a

user because you have the session you have the control in your hands and it is well suited for applications with modern

traffic and strict session requirements and in my opinion most applications should go with a stateful authentication

because because of the secure nature and the convenience of revoking tokens and revoking access of users and having

real-time information about all the users access and the challenges of a stateful authentication is of course uh

The Limited scalability issues and the higher operational complexity with distributed systems when you have

multiple servers in multiple regions and all you have latency issues and all so those are some of the challenges of

State full authentication in large systems in the same way a stateless authentication has Pros the cons of

stateful authentication are the pros of stateless authentication the pros like scalability and no session store

dependency and it's ideal for distributed architectures and mobile friendly applications where cookies are

not a thing and all those cons of stateful authentication are the pros of stateless authentication but the cons

are here is token revocation is complex and that is one major issue that once you issue a jwd token until it expires

you have no way of uh revoking access of that user um and it could be due to various reasons because the user account

might get compromised and the user contacted you using your support channels that the user wants to revoke

that session the user wants to uh stop access to their account so so you don't have any way of doing that apart from

changing your secret key of the JWT which will make all the users of your platform to log out which is a serious

inconvenience so what can you do in this Cas is you can device a devise a hybrid approach where the main web app the main

web app which runs in a browser you can choose stateful authentication for those clients you can have a hybrid approach

where you authenticate your browsers your web apps using a stateful nature and the servers uh and the clients that

use your apis in mobile apps where uh mobile apps or third party Integrations between different servers they can adopt

a stat stateless authentication for scalability and simplicity so you can have a hybrid approach like this to beat

the cons of both the authentication methods and now the third type of authentication method that we can

discuss is API key based API key based authentication K us to a completely different set of use cases as compared

to the stateful and stateless authentication so the primary reason people came up with API key based

authentication and before we get into that let me explain how it works so this is how it works uh you go to a platform

and you have access to the platform and you in the UI what you do is you go and click on generate an API keyy okay you

can generate an API key uh then you will get an cryptographically random string uh cryptographically safe random string

some some some string and you can use that string to gain access to the server which caters to this UI okay this server

which is responsible for this UI now you can directly gain access to this server using this API key this is primarily why

people with the concept of API keys so to give you one example everyone is familiar with the interface of chat gbt

right so in chat gbt you can open and you can type something in the search bar and you'll get an response you'll get a

response that is the UI okay that is the UI that we interact with but to cater to that UI there is somewhere in in the

cloud not one server there are a lot of servers those are the servers that are responsible to send the response

back to the client and the client renders that text in your UI in a very nice userfriendly way so that you can

read and you get what you are looking for that's how the typical interaction works but open AI the company that

created chat GPT they also have feature called API keys keys and why do people use that so that people who don't want

to use chat gbt people who have different use cases of the the model the llm model uh that powers chat gbd it can

be any model GPT 4 GPT 3.5 and all they want programmatic access to the server they want to let's say they might want

to create a different UI for their use case and they want the servers response the chity server response in that UI how

can they do that or they want the service response the response of jat gbt programmatically in their server they

don't want their UI they are building some server they want the response of open AI uh chat GB and different models

in the server programmatically okay not in terms of UI they need access in terms of programs for these kinds of use cases

to provide access to your server not your UI not your platform to provide access to your server to a different set

of users in a confined manner in a permission based manner in a expiry based manner to provide that kind of

access people have come up with API keys so that I can use this key whatever key that has been generated with some set of

permissions some set of expiry dates I can use this key and I can attach this key in some way in headers or depending

on the server's implementation I can send this key back to the charity server whatever ever the server that has

provided me with this key and I can do all the operations that the servers native platform can do I can also do

using the apis okay I can get the access to the server using the API key that's the primary use case of API keys and

people have come up with it for different different advantages first thing is uh they are easy to generate

easy to generate you just go to the UI you click on generate and that's it you get an API key and you can use that API

key to grammatically access the server second thing they are ideal for machine to machine communication what machine to

machine communication means is what we generally see or what we generally use is client to machine communication what

you can say client to server communication here we have a UI we interact with our Mouse we interact with

our keyboard we interact visually with the server right with the UI and the UI sends programmatic requests to the

server and the server does the business logic and sends a response back and the user renders those information renders

those responses so that we can understand and we can again uh interact with it that's how the interaction works

it's visual interaction it's client uh it's it's human interaction there is another kind of interaction which is

called machine to machine interaction machine to machine interaction so let's say I have a server okay I have a server

which to which I have a UI here for my platform and this is the server for my platform and this server

wants to use the chat gpts capabilities so let's say in my UI the user types something some string and the US send a

request to my server and says summarize this for me summarize this paragraph for me what I want to do I want to use the

existing capabilities of chat GPD server so that I can summarize that paragraph and send it back to the user now this is

called a machine to machine communication because my server visual machine there is no UI here there is no

human interaction here everything is done programmatically I have written code here in whatever programming

languages and that's how the server is running so This Server uses the API key that I have generated using chat gbt's

platform uh interface my server using this API key to make a request to the chat JD server and it identifies uh my

identity it it authorizes myself the my identity whatever plan I have whatever uh

quot I have remaining whatever access I have using this API all this information is maintained in the server site chat GT

server and they can identify they can find out that those information using the API key okay and I can use this key

and I can get response from the chaty server and I can send the response back to my UI so this is how a machine to

machine interaction looks like I can use my server to make request to other servers and get that response so it is

different from like visual interaction or human interaction or uh UI to machine interaction API keys are ideal for these

kinds of interactions because if because if you imagine in a typical in our stateful or stateless uh based

authentication methods we need visual triggers we need human triggers because there is a login form where we manually

have to type it out the username and password after to send this request there is uh some server validation

happens and the server sends back a GWT token and you have to save that suar and all these complex interactions require

some kind of human interference and that's why they are called client to servey interaction and in the machine to

machine interaction the a simple workflow is you provide the machine a secret key it saves that in whatever

environment variable or some kind of Secure Storage and it sends that in all the requests to identify itself instead

of doing all the username password token and all those workflows and API keys are ideal for those kinds of interactions

for programmatic interactions or machine to machine interactions now let's get into our last major type of

authentication which is O 2.0 or open ID connect whatever it is called okay why do we need this why did we come up with

it and everything surrounding it up until now up until now we have discussed different types of authentic State pull

and stateless and API keys and all we have a very simple setup right right we create an account with uh username and

password and every time you have to provide that authenticate yourself and you get a token and you return all and

that's how the whole workflow works and the more platforms you visit the more sites you visit in your computer in your

system the more credentials you create the more credentials you have to remember or the more credentials you

have to maintain if you use a password manager this approach became a little problematic why first thing is security

risk reusing password was very common uh during the initial era now I hope people have become more aware of this and they

use uh automatic password generators and password managers to maintain their passwords but during the initial

internet era reusing passwords like 1 2 3 4 5 or the string password was very common and a single breach compromised a

lot of accounts the first thing with this password based approach was Secure risks reusing the same kind of passwords

in multiple platforms or multiple websites the second thing is fatigue all this huge number of accounts

to manage was very overwhelming for a single user and that gave rise to what we call it's a very important Concept in

oath is called delegation Del sorry delegation what delegation means is we quickly came to a class of problem a

problem for example websites one website started needing access to other websites resources for

example a travel app a travel app like uh a hotel booking or a train booking app it needed access to access to Gmail

your Gmail account to scan your flight tickets to programmatically scan your flight tickets that is one example of

one platform one website needing access to resource of other platform the same way a social media app it can be

anything Facebook or Twitter or anything there social media app that wants to import contacts contacts from other

platform it it can be another social media platform or it can be your Google contacts anything right it wants to

import Resource One platform wants to import resource from another platform programmatically see now you see the

pattern this was a problem that this was a use case that we started to see uh which eventually uh gave rise to W so

initially what happened was the initial solution that people came up with this issue of how one platform or one website

can get get access to resources of another platform this is how you just use users came up with the solution they

what they did was they shared passwords they started sharing passwords and this was disastrous this led to so many

disasters because sharing a password meant giving full access giving access to everything in your account everything

in your system and there is no way to limit permissions and the second thing was it was impossible to re roke access

it is impossible to revoke access without changing your password everywhere since users used passwords

same passwords everywhere and providing your password to one platform so that that platform can access the resource of

another platform meant if you wanted to revoke the access permanently from your side you have to change your password

not just in this side you have to change your password from all sides because now one platform has access to your password

and it can do anything it wants which is a huge security issue that came up with this solution of sharing passwords for

giving platforms access to resources of another platform okay that was the solution people came up with initially

right now we have a problem that we called delegation problem a delegation problem which basically means providing

access of one platform to another platform providing resources of one platform to another platform

programmatically by a user and that was the time in 2007 the birth of O happened which basically meant open

authorization and it was not just a protocol it was a very revolutionary idea it it it it made so many things

easier so many things easier in our programming world that we have now so historically what happened was a couple

of engineer a couple of Engineers from companies like Google or Twitter started working

on standardizing a way so that users can access user can share access from one platform to another platform which is

the delegation problem and what they did was they were trying to find a way to do that without sharing passwords which was

a huge security risk so they came up with a technique of sharing tokens sharing tokens to share access

the idea was this token has specific permission so a password has all the access to your user account while a

token has specific access to a specific part of your account for example if you share your Google password with me I can

I can I have access to everything I can view your Google photos I can see your Google Maps history and I can look at

all your contacts and I can um see your your calendar I can add to your calendar I can remove everything I delete

everything I can do everything I I can I want using that password but let's say if you share a token and that token only

has capability to read my contacts okay not delete my contacts not add to my cont Del my contacts now I have

permission for a specific part of a specific platform that you access that you have that I can access now I can

read your Google cont tax so that was the idea that they came up with sharing tokens instead of passwords so there are

different components uh of the technique that they came up with first was the resource owner the second was the client

third was resource server and the fourth was authorization server and first thing who is the resource owner the user who

owns the data so in this case let's say it's you you are the resource owner who is the client the app that is requesting

access for example we have a uh social media app let's say it's Facebook and it is requesting access for your contacts

from your Google account so in this case client is your client in this case is Facebook who is the resource server in

this case it is your Google account which is the Google server the resource server is the authorization server this

is the server who issues the token the token for authenticating the user this is the token that is issued by the

authorization server after authenticating the user so this is how the typical flow of O 1.0 look like so

we are still talking about wor 1.0 we will we are yet to reach the wor 2.0 which came after this for a couple of

reasons that we'll discuss this is what the what 1.0f flow looked like first the client redirects the user redirects the

user to the authorization server OD server okay redirects the client to the OD server the client the client who is

the client in this case it is Facebook Facebook redirected you to the authorization server now what happens

next the user authenticates and grants permission you click on yes I allow and these are the permissions that I want to

give this server and you do that after that is successful in the third step the authorization server the server that you

authenticated that you give all the permissions to that authorization servers sends token to the client client

who is this client in this case it is Facebook it sends the token to Facebook now the client uses the token whatever

token it got from the authorization server it uses the token to access the resources what is the resource in this

case your context which is in your Google server so that's how Facebook a client get access to another platform

which is Google in this case another platform's resource which are contacts in this case programmatically without

you sharing the password with specific set of permissions so oath 1.0 solved this problem in a very beautiful way

which eradicated the problem of sharing the password to share access but then the oath 1.0 protocol evolved and we

ended up with oo 2.0 which came around 2010 or so oath 1.0 was pretty revolutionary it was pretty

useful but it had some limitations one of this was it was one of it was it was very complex for developers to implement

the whole flow was pretty complicated for developers at that time second it used cryptographic signature it used

cryptographic signatures which was very error prone so these are the two limitations technical limitations that

what o 2.0 did was first thing it introduced beer tokens which is much much much more simpler in the whole o

workflow it is more vulnerable but it made implementations more simple second it allowed developers it allowed

developers to choose flows based on the app type depending on whether the your app is a mobile or it is a server side

app or it is a device only app or like for example device code app for example Smart TV depending on different

different use case depending on your device that you are using these techniques on it it provided different

flows a couple of flows that you might uh hear is au code flow authorization code flow for server side apps server

side apps second implicit flow implicit flow for browser based apps which is now discouraged due to security risks third

client credentials flow for machine to machine communication machine to machine communication like communication between

two servers without any involvement of user or browsers or any human interactions and fourth is device code

flow device code flow is used in in devices where we have limited input where we don't have uh inputs like

keyboards and Mouse and all for example one of a major example is smart TV smart TV authentication uses a flow called

device code flow okay and o 2.0 came with all these features it came with bar token and it came with all these

different types of flows for different types of devices depending on where you are implementing your authentication but

one thing that I missed to say here was O was great for authorization was great for authorization but but it did not

solve the issue of authentication so if you remember authentication is providing an identity saying who you are and

authorization is saying what can you do what all permissions do you have what all capabilities do you have in the

platform and authentication is who are you in the platform what is your identity what is your name what is your

ID and all and authorization is what is your permission okay so o solved the issue of authorization using delegation

but it did not solve the issue of authentication so that's when in 2014 or so people came up with open ID

connect or simply called oidc which was built on top of O 2.0's security mechanisms to fill the gap of

authentication in the whole authorization workflow so this is how it works what oidc did on top of oath was

open ID connect extended o 2.0 by introducing what you call it ID token we did not have that in O 2.0 and the ID

token was typically a JWT we have already discussed JWT for the reasons for reasons like this because we will

keep coming across JWT is in multiple areas of authentication and authorization that's why we discussed

about jws in the initial part of the video so what open ID connect did was it introduced a concept called ID token in

the O 2.0 workflow an ID token was nothing but a JWT which had information like user ID when they

logged in which happened because of the field issued at and the issuing authority who issued the token who was

the authority who was the platform that issued the token to this user and all this information that was in the

JWT the JWT also had information like the user's name and the users email and all the information that the needing

party once from the other platform and because of open ID connect now you can go to any platform and major pretty much

all the platforms have this feature now you can do sign in with Google sign in with Facebook sign in with Discord and

those features use open ID connect behind the scenes to take your identity from let's say you do sign in with

Google so what happens is it takes your identity your email and your Google image your Google profile picture your

name and all whatever the profile information it asks for it takes your identity from Google and it stores in

their database or it just uses that to identify you to authenticate you using Google without having its own

authentication mechanisms so that's the use of open ID connect it introduced a layer of identification on top of O 2.0

so this is how a typical open ID connect based workflow works works first thing the client in this case so let's say you

went to a platform you went to a platform for note taking the client and you click on sign in with Google so this

client the not taking app it redirects you to the authorization server we discussed about authorization server

just before it redirects you to the authorization server the user logs in into the Google account since they did

sign in with Google they log Lo in using the Google account from the Google's authorization server not from the

client's server they do it from the Google's authorization server they login they provide whatever permissions that

was asked by the client for example reading the users email or the name or the profile picture whatever you grant

those permissions and the authorization server sends two things a authorization code an authorization code and an ID

token back to the client to the not taking platform then what the client does in the second step it uses the code

and an ID token is optional at this stage in some workflows and when the client uses the Au code the

authorization code in the Second Step It exchanges the authorization code with the server with the with the resource

server for a access token for a access token on behalf of the user and an ID token if did not get the ID token in the

first s it gets an ID token toen in the second step and the ID token will have jws and inside the JWT it will have the

users's ID users name different values of the user and the access token using the access token the not taking server

the client can do different different operations on behalf of the user in the resource server so now let's say the not

taking server asked for Google keeps access okay all the notes that you have in your Google keep it ask for that

access during the authorization workflow so and you granted that access now when everything is done it uses the Au code

to get this access token now the note taking server can store this token this access token and it can get all your

notes from Google server using this access token on behalf of you now that's the use of open ID connect now the

client platform the not taking platform can authenticate on behalf of you it can pose as you it can appear as you to the

Google server and it can ask for stuff whatever the stuff it asked permission from you not any uh kind of stuff only

the stuff it has permission for in this case all the notes from your Google keep okay that's how the whole workflow works

so you can imagine or 2.0 and open ID connect together as security guards or key makers of the digital age of the

digital Modern Age they ensure that no one not a user or a platform gets more access than they need or then they have

asked for in the first place from the user so they only get access to those resources that they have access for that

they have permission for and protocols like o 2.0 and open ID connect make sure that it happens it stays like that and

together these two revolutionary technologies have transformed the internet from a password sharing

chaos into a secure into a secure modern interconnected system and because of these two technologies we have so many

new features in so many platforms that we can integrate one system into another we can do different types of uh resource

sharing we can type do different types of permission sharing and all those different things that can happen because

of O 2.0 and open ID connect now the question is when should you use which type of authentication now that we

discussed the four major types of authentication that we use uh in the modern age that you should be aware of

as a backend engineer which technique which type of authentication that you use in which kind of situation so this

can help you decide on that so these are some of the thumb rules stateful authentication using a session ID or a

GW taken and a persistent storage you use stateful authentication for typically all your web app based

authentication work workflows uh which comprise of pretty much a large portion of our SAS based models right that's a

stateful authentication is ideal for that kind of scenario where user specific session data is stored on the

server okay State stateless authentication is ideal for apis or scalable systems which have distributed

servers all over the world and where tokens carry users info or users data we have o authentications

this is ideal for third party Integrations and providing login via external providers like Google Facebook

Discord and all we have API key based authentication which is ideal for server to server or machine to machine

communication or a let's say single purpose client access to apis so that's pretty much all the four kinds of

authentication and a simple thumb rule to decide you on when to use what in my experience you will use stateful

authentic and stateless authentication most of your times when you're building your apis okay and with that we have

pretty much talked about everything that you need to know as a backend engineer about authentication that you need to

understand about authentication and now we can move on to authorization this is not as vast as authentication but just

you can still get an high level idea of what it is about as I have already mentioned the the on line explanation of

of authorization is authentication is basically the who which means who the identity of the user and authorization

is the permissions of the user what a user can do and authentication is who the user is in the platform those are

the two questions that can help you understand the difference between authentication and authorization now

moving on to authorization what was the need of it why did people come up with this concept called authorization

circling back to our example let's say we have a user that logged into our system we have a server

and let's say it's a not taking platform it's a not taking platform and the user logged into our platform or logged into

our server using the appropriate credentials so it provided the email or password or whatever the credentials

need are and it authenticated itself into the platform now it can create notes it can delete notes it can update

notes whatever the typical function it of a not teing platform is that's one part second part comes is you as the

creator of this platform is a creator of this platform you need to your platform has an ability or let's say a delete

feature and the delete feature actually does not delete the note permanently it stores the note in kind of a recycle bin

or a trash can so the user has the ability they can either delete it permanently or it will will get

automatically deleted after 30 days after 30 days let's say all these notes move into another Zone they get deleted

for the user but it don't get permanently deleted from the database they move into another Zone let's call

this dead zone it all the nodes after 30 days they move into this Zone called Dead Zone okay and now the requirement

is you as a creator of the note taking platform you want to is these notes programmatically using another UI called

admin UI so you are the administrator you're the Creator UI or another UI called Creator UI you as an

administrator of this platform or a creator of this platform want to have some permission some capability which

are not granted to all the users of this platform which are not granted to every user you want special permissions for

this platform and you want to create another UI for yourself in for this case one solution for that is one solution

for that is you can let's say come up with a random string and you can send the string with each API and using that

you can say that okay so uh the server will identify that this is coming from the Creator give the access to those

capabilities which are not accessible to all the users now the problem with that is this is this has security flaws since

you are sending this special string this is this god mode string in your apis if someone intercepts this string they get

hold of the string they can do a lot of uh disastrous thing to your platform they can entirely clean the DB they can

mess with other users data they can do a lot of Stu there is a huge security risk with this approach that is the first

part the second part is what if you want to give the same level of access the same level of special access to other

users other users let's say to your friends are people who regularly maintain the platform you want to give

them these special permissions so now you have to either give that string to them or you will create more strings and

add the support in your server to allow for those strings for the special permissions now as you can see the

system just got more complicated than it was before and it is very difficult to manage the access now and it is more

prone to security flaws use cases like this use cases like this I have oversimplified the use case but all in

all what you can see is providing specific permissions providing specific

permissions to specific users on a platform is basically called authorization what authorization means

is not all users in the platform have the same level of access not all users can do the can do the same thing some

users have different capabilities some users have more capabilities some users have less capabilities some users have

completely different set of capabilities than the other users and if you're building a multi-tenant architecture

let's say you are providing users to create organizations and in that organization you want users the admin to

provide different permissions to different kinds of members so you want to provide you want to provide the admin

the capability so that the admin can assign read or write permission to some users and only read permissions to some

users so because of the need of these kinds of scenarios people came up with authorization techniques and one of the

most famous ones that we use still in the modern age that you as a backend engineer should be familiar with is

arback which stands for role based Access Control okay and it's called role based access control because this this

is how it typically Works in a typical platform we have different roles one can be a user role it can be an admin role

it can be a moderator role we have different roles and different roles are assigned different set of permissions

let's say a user role is only assigned read permission admin role is assigned read and write permission same way a

moderator role is only assigned read and write permission depending on the role and you can create create your own

custom roles with own with its own set of permissions on different different kinds of resources let's say a notes

users have read write and delete but on a different resource let's say accessing The Dead Zone notes that permission is

only provided to admin you can go as granular as you want using different roles and permissions and that's all

there is to it in our back and authorization so this is how a typical workflow works so in a platform a user

registers or a user signs up and the server assigns it a role let's say it assigns it a user role or depending on

the use case it assigns it a admin role and in the subsequent request once the user sends its token or it could be

session ID using stateful session ID using stateful authentications or a JWT using stateless authentication whatever

the means of authentication it is it sends its identification and the server can deduce what is the

role of the user using that token or it can do a database lookup and see what the assigned role of that user is

whether the role is user or the role is admin and depending on the role of that user that is deduced early in the

request cycle and it is passed on to the next set of middlewares uh we'll talk about middleware and how the middleware

chain works in the in a future video but imagine in the first entry point the server checks your uh your identity and

checks your role and it attaches that information so that the next set of code the next set of logic that next set of

logic can have access to this information so that they can decide whether whether a user has access to the

dead zone notes and the user will have access to the dead zone notes if the role is admin and if the user role is uh

user if the role is user then the API will fail and it will the server will send an error called forbidden with

status 403 which means you don't have enough permission to perform this task or access this resource that's the whole

idea of arback role based access control and that's pretty much all you need to know about authorization and our back

since we are talking about authentication authorization and it's in the context of back and Inus two things

that I want people to know these two things is sending appropriate error messages in

the authentication workflow and some info about timing attacks so the first thing error messages during the course

of authentication there will be instances when you have to send messages to the client the user logs in with a

certain email and you could not find that email in your database and you send a very helpful message called user not

found or let's say the email was found but the password was incorrect so you sent a friendly message called incorrect

password the same way the user tried invalid credentials for sometimes for invalid credential for

a few times and you send a message account locked due to too many failed attempts and while these messages are

helpful for legitimate users they also provide attackers with clues for example if the error indicates user not found

the attacker learns that the username does not exist and if they're trying to breach users some users account they

will move on to the next user they will try with a different email and they will keep moving on to the next users if they

have a certain list of users they that they want to breach the same way if you send a message called incorrect password

now the attacker knows that the username was correct and now they only have to breach the password so they will try a

list of brute passwords using brute forcing or dictionary attacks and they will there attack surface will increase

because they had some kind of confirmation from you as a server as a backend engineer you should be aware

that never send specific messages when it is about authentication right never send friendly messages like these always

keep any message related to authentication generic so you can do you can save authentication failed you can

do authentication failed for all the three cases does not matter what happens what kind of uh authentication failure

happens always send a generic message to the client so that the attacker is always uh confused if if it's an

attacker it's confused that what is the next set of actions it they should take to breach the system that's one

important thing you have to remember always send generic error messages during your authentication workflow

during your authentication life cycle do not send friendly client friendly or user friendly error messages

particularly in this workflow you can send user friendly error messages during other workflows like validations or

other apis in the security World there is another kind of attack even though it is rare it is called a timing attack and

how it works is in a typical authentication workflow when the user submits their credential the email and

the password first the server verifies the the username or the email or the username whatever it is provided for the

first field it verifies it if it tries to find if it exists if the user exists in the platform then the next step is if

they are handling it they check if the account is locked or if the account is suspended for a few time because of a

couple of invalid credentials that the user has tried with in the near past so servers have this mechanism where they

lock a a particular user account for some time for 2 minutes or 4 minutes or a day if they try too many invalid

authentication attempts so the second step is first step is find user second step is check if they are locked okay if

they are not locked third step is comparing the password the provided password with the stored hash the stored

hash that the server has stored in the database because passwords are not stored in plain text when you sign up

into a platform your password is taken they're hashed into a particular cryptographically safe string then they

are stored in the database and there is no way to get the plain text value of that password even for the server right

the server can only encrypt that password in into a particular string and then it can store that password so that

so that the next time you provide your password it can compare it can hash that password it can encrypt that password

into the same form it can fetch the previously stored password from the database and then it can compare those

two that's the way servers check if the password is correct or not that's the typical workflow of checking if the user

has provided correct password or not they take the provided password they hash it using the same algorithms using

the same key and they check that version with the stored hashed version in the the database and they check if they are

same or not they're not same then the password is incorrect okay that is the third step check password and now the

problem here is if the username is invalid if the username is invalid in the first step the system will terminate

there only and you will get uh some response that user not found and that will have a faster response time as

compared to the system failing at the third step at the third step where username is is valid but the password is

incorrect In this case the response will have some kind of delay because it failed in the third step and the system

will take a little longer due to the additional step of hashing the password hashing the password takes a little

longer than doing the other operations that's why if the username is invalid the system will have a faster response

if the password is invalid system will have a little delay in the response and use using that parameter that delay

whatever 200 milliseconds or whatever the delay is attackers can can find out whether that username was correct or not

or at what step the server failed to authenticate and they can find if the usern name was invalid or the password

was invalid and they can use this strategy and they can use this information to further strategize their

attack plan they can decide whether to Target on the username or to Target on the password based on brute force or

dictionary attacks and all so what you can do is as a backend engineer to defend against these kinds of timing

attacks you can you have to make sure that authentication systems must introduce measures to equalize the

response times one method you can use is constant time operations there are some cryptographically secure constant time

comparison functions for password hashes these functions ensure that execution time does not vary based on the input

similarity that is one method you can use the second method that you can use this you can simulate a response delay

uh using whatever programming language that you're using if you're using node just you can do set timeout or if you're

using goang you can do time do sleep so you can do a simulation so that even in case of username not matching the system

does not send a response immediately it simulates some kind of response like 200 milliseconds of delay and then send a

response so that the attackers cannot measure the timing differences between a username failing and a password failing

because you are simulating a fake delay but these are the two major kinds of security related information that you

should have in mind while you are implementing authentication and authorization and with that that's all

about authentication and authorization that you should know as a backend engineer and in the next video we will

move on to validations and transformations