HTTP auth basics or how websites who know you are

So when you're learning web development, you'll hear about HTTP pretty early on. HTTP is basically just the rules for how your browser and a server talk to each other.

You ask for something (a request), the server responds. That's it. But here's the thing, because HTTP by itself is "stateless," which means every single request is treated like a brand new conversation.

The server has zero memory of who you are between requests. So how does Netflix know you're still you when you click on a new show? That's where auth comes in.

Authentication (who are you?) and authorization (what are you allowed to do?) are systems that developers build on top of HTTP to solve that memory problem.

The most common ways to do this are cookies, tokens (like JWTs), and sessions. When you log in, the server hands your browser a little piece of identifying info. Then your browser quietly attaches that info to every HTTP request going forward, so the server can recognize you. Authentication checks your identity, and authorization checks your permissions, like whether you're allowed to access the admin dashboard or just the regular user page.

If someone asks you "how does login work?" or "what's the difference between authentication and authorization?", this is what they want to hear.

Understanding that auth is a layer built on top of HTTP (not magic baked into it) shows you actually get how the web works under the hood, not just how to copy-paste a login form.