Authentication and authorization 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