Design a Simple Authentication System | System Design Interview Prep
ฝัง
- เผยแพร่เมื่อ 14 พ.ค. 2024
- Visit Our Website: interviewpen.com/?...
Join Our Discord (24/7 help): / discord
Join Our Newsletter - The Blueprint: theblueprint.dev/subscribe
Like & Subscribe: / @interviewpen
This is an example of a full video available on interviewpen.com. Check out our website to find more premium content like this!
Problem Statement:
Design a simple authentication system that allows services to identify clients. Clients should be able to register their identity, log-in with their identity, & end active sessions.
*Resources:*
- [Stateless Protocols](en.wikipedia.org/wiki/Statele...)
- [JSON Web Tokens](jwt.io/)
Table of Contents:
0:00 - Introduction
1:08 - HTTP → Stateless
2:10 - Visit interviewpen.com
2:29 - Continuing On
3:49 - Sessions
5:35 - Authenticating Requests
7:21 - Session Token Storage: Cookies
8:16 - Cross-Site Request Forgery (CSRF)
8:54 - Local Storage
9:37 - Architectural Concerns
10:44 - Decentralized Auth
11:48 - JSON Web Tokens
14:17 - Token Lifetime
15:18 - Recap
16:47 - Visit Us at interviewpen.com
Socials:
Twitter: / interviewpen
Twitter (The Blueprint): / theblueprintdev
LinkedIn: / interviewpen
Website: interviewpen.com/?...
Thanks for watching! Visit interviewpen.com/? for more great Data Structures & Algorithms + System Design content 🧎
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.
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 👍
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.
@@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
@@interviewpen I'm enjoying your videos. Thanks for the content
he also didn't talk about refresh token
I'm glad I found this channel today. I've shared it on my page! Good content! 👌
cool! thanks for watching - more coming
Great content for any one who wants to understand designing systems.
thanks for the kind words - thanks for watching! more coming!
Thank you for your great efforts!
Sure
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!!
thanks for watching 👍
nice explanation!! hope you guys release more videos on system design
We will! Stay tuned - we're just starting up.
Thanks, great explanation!
thanks for watching! more coming!
This is gold. Happy to get here early.
Thanks for coming here early. We will be posting a lot more. & growing!
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.
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!
Inspiring ❤
Good luck chasing the rabbit hole 😅🤗
thanks & could you clarify on the second remark? - thanks for watching!
Really worth it.
Thanks!
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!
Thanks for watching and great thoughts!
Brilliant!
Thank you!
well done!
thanks! and thanks for watching!
well explained
Thanks!
This is Golden
Glad you enjoyed it, check back for more.
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.
Cool, thanks!
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
Yep, cookies are definitely a more secure approach in the majority of situations. Good point; thanks for watching,
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?
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!
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?
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!
COOL!
thanks for watching
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?
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.
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.
Yes that's correct, using JWTs and cookies go hand in hand. Thanks for watching!
Thanks for content.
What tool you were using for drawing?
Glad you enjoyed it! We're using GoodNotes on an iPad.
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?
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.
@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.
Hi, thanks for the explanation! What about ban system for the auth via JWT? Can you revoke the JWT?
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.
I missed what is JWT, is that some JAVA standard library? I come from PHP.
JSON web token
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 ?
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!
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.
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!
@@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?
9:45 what if the session tokens are cached in Redis?
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!
Plz do a simple mmo next!
We'll add it to the list. Thanks for watching!
thanks bruuuuuuuuuuuuuuuuuuuuuuuhhhhhhhhhhhhhhhhhhh!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
You're welcome :)
Never ever use local storage for auth services on the client.
Never say never, but yep, generally a best practice to use cookies for security reasons.
You forgot to mention using a trusted SSL which would prevent man-in-the-middle proxy attacks!
Yes, under all of these schemes having an encrypted communication channel is critical. Thanks for watching!
5:35 i think JWT also solve that problem is it ?
Exactly--decoding a JWT and looking up a session in a database are two approaches to this problem.
The state of http is that it is stateless?
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.
@@interviewpen Thanks.
can you tell the pen you're using and the board ?
Yep! GoodNotes + Apple Pencil.
@@interviewpen thank you so much
Can we design a banking app?
Yes - I added this to our backlog of topics to cover.
@@interviewpen thanks btw love what you doin so much to learn from this.
3:35 what if the attackers name is also Bob
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.
Nice content, but I had to struggle with the accent. Wish the video was a bit slower and clearer.