Design a Simple Authentication System | System Design Interview Prep

[@interviewpen]

Thanks for watching! Visit interviewpen.com/? for more great Data Structures & Algorithms + System Design content 🧎

[@Jeanpierrec19]

Do not use local storage for session or token storage... Local storage can be read by any JS running on the page, including external extensions. HTTP Only, Secure cookies exist for a reason. Also you entirely missed another of the great security abbreviations, CORS which is vital for securing modern endpoints in browser.

[@interviewpen]

To the first part - correct. HttpOnly cookies provide a thinner attack surface so you can't just swipe the token with XSS & do remote attacks. You can still trigger "on-site" requests that pass authentication, but that is a more limited attack surface (good StackOverflow comment: stackoverflow.com/a/62967634/4493060). To the latter point - we have a lot to cover in these videos and try our best to make them as complete as possible given the time constraint. We'd love to cover CORS & browser security in later stuff we post 👍

[@Venistro]

If an attacker can execute their own code on your website, it's game over anyway. Even an http-only cookie is of little help then. But then you have to protect yourself from CSRF, which is not difficult, but another point that can be faulty. If you structure your scripts properly and use CSP, you can prevent that someone simply executes inline javascript code or scripts from unauthorized origins, which on the one hand greatly reduces the attack surface regarding tokens in the local storage, and on the other hand protects the application in general.

[@Jeanpierrec19]

@@Venistro An attacked can execute their own code on your website through both XSS as well as through a supply chain attack. Likewise if the cookie is in an httpOnly Secure cookie the attacker would need to compromise the browser itself or your backend to get access to the token, it literally cannot be access from the website itself. As a third point it is literally setting a header on the backend server vs sending a token over the wire and needing to make 2 client side JS called for every single API call from your website. With a cookie the browser just happily sends it along. Localstorage isn't recommended for anything security related, if your code ever needs to undergo a security audit it will be finding so why not do it correctly from the beginning. We are talking about auth here, it's important to get it right

[@Jeanpierrec19]

@@interviewpen I'm enjoying your videos. Thanks for the content

[@mrlectus]

he also didn't talk about refresh token

[@Gorlung]

I had insomnia, but now, thanks to the vlog, I fall asleep within minutes watching the videos!

[@jamilxt]

I'm glad I found this channel today. I've shared it on my page! Good content! 👌

[@interviewpen]

cool! thanks for watching - more coming

[@f41z37]

This is gold. Happy to get here early.

[@interviewpen]

Thanks for coming here early. We will be posting a lot more. & growing!

[@tenthlegionstudios1343]

Very interesting. One thing to mention is generally with tokens the server side still needs to maintain a blacklist of revoked tokens. As well as share the key/secret that is used to sign the token across services when horizontally scaling. Things like OAuth partially remove the XSS concerns since the service you have talks to Google or whatever you are using for OAuth. This way the auth tokens / jwts live on the servers. I have never been able to convince myself if tokens or sessions are better. But it is definately easiest and best to use somthing like OAuth when creating your own service instead of trusting yourself to do auth yourself :) Or at least I dont trust myself to do auth. Thanks for the content!!

[@interviewpen]

thanks for watching 👍

[@سنابل-الفردوس]

"don't make your own auth" is a bad advice cuz i have seen an ethical hacler that said he got into companies emails using apple's oauth

[@yuganderkrishansingh3733]

Great content for any one who wants to understand designing systems.

[@interviewpen]

thanks for the kind words - thanks for watching! more coming!

[@zeyad3k]

There is another drawback of using JWTs and that is the limited amount of data that you can store in the payload. I think having a centralized session storage like Redis might be a better solution. I’d love hear everyone’s thoughts on this.

[@interviewpen]

Really good point. I often see JWTs used for more simple authentication scenarios, and when there's more complicated requirements, centralized session management becomes necessary. Thanks for watching!

[@Shiftito]

Hey, great video and channel, thanks! I can't help but share my first thought whilst watching this video (instead of going into details like sessions and tokens) - these days it's fundamental to swap "Consider Security" with "Security as a core requirement". It sounds like a small detail but it's an important mentality shift to have. It really makes things simpler (and cost-effective) in the long-term, but sadly the trend is still to have security as an afterthought. The problem arises when its need becomes apparent; implementing effective security measures retroactively is often a nightmare, especially when things have scaled massively. This is where this "Secure by Design" thing comes from ^^ in this case; strong authentication, proper accounting & alerting, data integrity, confidentiality, non-repudiation...they're all elements security can address :) My 2c, cheers from Australia!

[@interviewpen]

Thanks for watching and great thoughts!

[@machj2592]

nice explanation!! hope you guys release more videos on system design

[@interviewpen]

We will! Stay tuned - we're just starting up.

[@emersontavera9362]

I think I might prefer a backend for frontend approach, we can set up an api gateway which exchanges a session id coming from the frontend for an access token or refresh token if that access token is no longer valid, in this way, tokens never leave the server and we just share a session id with the client which has to be stored in a http only cookie. certainly every system has its own specs, so we can't use the same formula for everything, nice video.

[@interviewpen]

Cool, thanks!

[@bal6464]

Inspiring ❤ Good luck chasing the rabbit hole 😅🤗

[@interviewpen]

thanks & could you clarify on the second remark? - thanks for watching!

[@ideiasBrasil2023]

For godsake do not use local storage for storing tokens. You should be using only http-only cookies that are not readable on client side

[@interviewpen]

Yep, cookies are definitely a more secure approach in the majority of situations. Good point; thanks for watching,

[@igorsantanas]

Thanks, great explanation!

[@interviewpen]

thanks for watching! more coming!

[@haroonrehman8156]

Really worth it.

[@interviewpen]

Thanks!

[@YangJimmy-go6no]

Hi thanks for your video! I still got a question that I want to ask. If we do in a JWT way, isn't the JWT still stores in the cookies? I think it is still the cookie based storage. Then what is the difference between JWT and the cookie based storage you mentioned in the earlier of this video.

[@interviewpen]

Yes that's correct, using JWTs and cookies go hand in hand. Thanks for watching!

[@jayantpant5887]

This is Golden

[@interviewpen]

Glad you enjoyed it, check back for more.

[@mdk1983]

Brilliant!

[@interviewpen]

Thank you!

[@irascib1e]

9:45 what if the session tokens are cached in Redis?

[@interviewpen]

Great question--caching sessions in an in-memory database is a great performance optimization if taking the centralized authentication approach. Scaling Redis is still a consideration though!

[@yuganderkrishansingh3733]

Isn't leak of JWT token a bad thing? IMU if it's leaked the User2 can easily impersonate as User1 and can make requests on their behalf and is possible as u mentioned humans are biggest concern for security in a system. I would try to scale my db by lets say introducing a cache for session than compromising on security aspect by introducing JWT token which is just introducing security issues. Kindly correct if wrong.

[@interviewpen]

To the first point - yes if the JWT itself is compromised you are subject to replay attacks, the security is only in that you know "who is speaking" and no one can forge their "voice". But you can replay a payload, yes. One solution is to fill out the "exp" field and have an expiration on a payloads validity, etc To the latter point - I'm not fully sure what you mean? Thanks for watching!

[@yuganderkrishansingh3733]

@@interviewpen Thanks for the reply. In second point I am just pointing out that we may also try an approach where we front our DB with a cache and store session tokens there. Wont' that help with managing load on db and we more favorable security wise compared to token approach?

[@mark601]

So using decentralized the user API queries the login API before executing anything to obtain the matching token? I'm still not sure if I follow how DB2 knows the token issued by DB1. I really like the idea of the resilience you gain from this approach though. To a large effect it's something one could overcome the need for and still gain the benefit from through auth federation and SSO.. right?

[@interviewpen]

Yep, with JWTs, the user can generate a token which is cryptographically signed by the login API. After that point, any other API can simply verify the signature and know whether the JWT is real--no database lookups necessary. And federated authentication can still be done using JWTs.

[@TonyLeung-e5u]

well done!

[@interviewpen]

thanks! and thanks for watching!

[@NoName-ef2gv]

Thanks for this video! Great explanation! I was wondering, besides having a time duration, is there any other way to log out user for the decentralized authorization?

[@interviewpen]

Unfortunately there isn't much that can be done for sign out with JWTs. You could make a list of banned tokens, but this would end up adding overhead to requests (the same reason JWTs are beneficial in the first place). Glad you liked the video!

[@anubhavkumarrao3141]

well explained

[@interviewpen]

Thanks!

[@user-QesOrwuMqN]

Hi, thanks for the explanation! What about ban system for the auth via JWT? Can you revoke the JWT?

[@interviewpen]

Well you can just stop trusting the identity that is sending the signed JWT. JWTs are just a standard for sending information signed by a sender for the receiver's verification If you are using a symmetric signing key - you can just no longer listen to messages signed with that key. If using an asymmetric key, just stop trusting the identity that the public key signifies and drop the request / reject with 403 Forbidden.

[@gmanonDominicana]

I missed what is JWT, is that some JAVA standard library? I come from PHP.

[@mohitkawle9676]

JSON web token

[@codewithawaisahmad]

awesome explained

[@interviewpen]

Thank you!

[@user-maymay2002]

why are people talking about storing tokens in a local storage? What are we supposed to do if that's not the case then?

[@vivekgujari9118]

I have a question. Everytime when a user logs in, the system will generate a session token regardless of if it is a good user or a bad user. How this session token differentiates between the good and bad user?

[@interviewpen]

When we log in, our authentication system has to verify the user’s credentials and generate a session token. If the user doesn’t have the right credentials, the system will reject the user and will not generate a token. Hope that helps!

[@marvinxulu7816]

Just to get things clear, You have twoo seperate apis one is for auth and the other is for users and they use seperate dbs ?

[@interviewpen]

The users API is an example to show an operation that requires someone to be authenticated. In this case, the users API would in fact need to write to the authentication database, but the main point is that the users API doesn't have to read from the database to check that the person accessing it is authorized. Thanks for watching!

[@cbbcbb6803]

The state of http is that it is stateless?

[@interviewpen]

Yes - HTTP (Hypertext Transfer Protocol) is a stateless protocol. Being stateless means that each request made from a client to a server is treated as an independent transaction, with no knowledge or memory of previous requests. In other words, the server does not maintain any information about the client or its requests between different transactions.

[@cbbcbb6803]

@@interviewpen Thanks.

[@dmitrykuleshov7134]

Thanks for content. What tool you were using for drawing?

[@interviewpen]

Glad you enjoyed it! We're using GoodNotes on an iPad.

[@lazivi]

5:35 i think JWT also solve that problem is it ?

[@interviewpen]

Exactly--decoding a JWT and looking up a session in a database are two approaches to this problem.

[@noahginsburg6140]

Once your are generating the JWT and returning it from your login service, do the other APIs still need to talk to the login service to determine if the JWT is legit before letting the api call proceed? Or do all other services know the signature to look for and no further communication to the login service to verify is needed?

[@interviewpen]

Exactly, other services can take advantage of the cryptographic signature to verify the integrity of the JWT themselves; no communications to the authentication service are necessary. Thanks for watching!

[@xerohr]

If JWTs include permission info (ie. "admin" role) to decentralize, what's to stop a user from just changing the permission info in the jwt?

[@iustall]

if any information in the payload changes, the signature (which is generated using the secret key) for that data also changes. If you change something inside the payload but keep the same signature, the server that verifies the token will see that it is not valid.

[@interviewpen]

@claudiucristea4177 is correct here :) The data in the payload is signed so the service will be able to detect if the data has been tampered with.

[@eazypeazy8559]

COOL!

[@interviewpen]

thanks for watching

[@zohaibakber3056]

Can we design a banking app?

[@interviewpen]

Yes - I added this to our backlog of topics to cover.

[@zohaibakber3056]

@@interviewpen thanks btw love what you doin so much to learn from this.

[@RAMII19780529]

I'm not trying to be difficult, but I don't understand how using a bearer token or jwt is any different / better than having the user send their username and password with each request. If the bad actor has a way to see the request, they could just copy and use the token, just the same as they could copy the username and password, which needs to be sent to create a token to being with. I think this is why using HTTPS is so important.

[@interviewpen]

This is true, but tokens can expire, so obtaining one is not as problematic. Furthermore, the impact is scoped to a single system, even if the user uses the same password for multiple systems. Thanks for watching!

[@RAMII19780529]

@@interviewpen Thank you, those are good points for me to consider.

[@ajalanbrown2200]

thanks bruuuuuuuuuuuuuuuuuuuuuuuhhhhhhhhhhhhhhhhhhh!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[@interviewpen]

You're welcome :)

[@dhrubajyoti3774]

the tool name for drawing or writing here ?

[@interviewpen]

We use GoodNotes on an iPad. Thanks for watching!

[@irascib1e]

3:35 what if the attackers name is also Bob

[@interviewpen]

Right--this is exactly the problem we're describing; our authentication system has to verify who the user is. Also "Bob" is just a placeholder for demonstration--in reality, we'd likely have a unique ID for every user.

[@khaledhosni1392]

can you tell the pen you're using and the board ?

[@interviewpen]

Yep! GoodNotes + Apple Pencil.

[@khaledhosni1392]

@@interviewpen thank you so much

[@buddysteve5543]

You forgot to mention using a trusted SSL which would prevent man-in-the-middle proxy attacks!

[@interviewpen]

Yes, under all of these schemes having an encrypted communication channel is critical. Thanks for watching!

[@austin2994]

Plz do a simple mmo next!

[@interviewpen]

We'll add it to the list. Thanks for watching!

[@ayushjindal4981]

Nice content, but I had to struggle with the accent. Wish the video was a bit slower and clearer.

[@KevinBoutin]

Never ever use local storage for auth services on the client.

[@interviewpen]

Never say never, but yep, generally a best practice to use cookies for security reasons.

[@nirmalgurjar8181]

@@KevinBoutin we can use local or session storage to store session tokens and not any other auth details. this token can be send in each request to handle CSRF. session id and other detail would continue to be in cookies but without session token url is prone to CSRF.

[@TheMdaliazhar]

Explanation is good but Its not comprehensive. One can't quality a system design interview based on above video for the given topic.

[@interviewpen]

Ok, could you elaborate on what we're missing?

[@nirmalgurjar8181]

This guy is talking like Sidhi baat no Bakwas.