Security is one of those big, hairy, scary topics that can stop you from ever building something real while vibe coding, especially if you’re new to coding. I can’t cover all of it (there are literally thousands of entire books on the subject), and this is going to be a series, so I’m starting with one piece: Authentication, aka who’s allowed in.

Authentication is just one piece of the plumbing that holds a real app together. If you want the full map (hosting, APIs, backups, and the rest), start with how I’d approach learning to build apps today.

First, watch it happen for real

Humor me for sixty seconds. Before I define a single term, I want you to go see authentication happen with your own eyes. It’s something you’ve experienced thousands of times, but have you ever actually seen what’s going on under the hood? Don’t worry if the terms are unclear or confusing, I’ll explain everything that’s happening after this.

If you’re on a desktop browser (unfortunately, not on mobile. But I’ll also describe what you would see), do this:

  1. Go to your favorite website where you have a username and password
  2. Right click, hit “Inspect”, and switch to the “Network” tab
  3. Enter your username and password and then click submit
  4. What’s that? Something new in the network tab?? a POST request to a url ending with /login or /auth or /token or something that sounds authentication-y?
  5. Click on that shit!
  6. You should see a “Headers” tab with a status code (likely 200 if you typed your password correctly)
  7. Click the “Request” or “Payload” tab (depending on your browser) and you’ll probably see your username and password sitting right there. That’s wild! NOTE: as long as the site has https:// at the beginning, this will be encrypted before it’s sent across the internet.
  8. If you click on “Response” you’ll probably see what the server responded with. This could be a token, a cookie, or something like that. A token is just a long string of letters and numbers that’s unique (think a really long password) that typically has an expiration date (so it doesn’t last forever).
  9. That token (or a lot of times in the browser a cookie is used) is passed with all further network requests. The server can use that token to validate who you are! And that’s why once you login to reddit, or whatever site, you can see only your own data. That’s how you’re “logged in”.
  10. Ever been on a site and then when you click on something or refresh the page it takes you back to the login page? That’s because the token expired! Pretty cool right?

So what the hell was all that?

Everything you just watched in the Network tab was your browser talking to a server using something called a REST API. (Wait! Don’t close the window! I know your eyes just glazed over with an acronym like that. Good lord, I know mine did. I swear I’ll try to make it interesting and relatable and skip over all the boring stuff)

I’m not going to bore you with what it stands for. Just know it’s how most modern web applications communicate with each other. The client (your browser) needs a way to send data to and receive data from the server, and REST is that way. Every one of those events flooding your Network tab when you refresh the page? Those are API calls!

With REST APIs there are several different actions that you can take. The main three that you’ll see the most are:

  • GET - essentially retrieve/read data
  • POST - typically creating data
  • DELETE - you guessed it! Reading again! (jk, deleting ;D)

There’s more to it than that, BUT, it’s probably enough of a baseline for me to give you an understanding of how Authentication can work using REST APIs. NOTE: This is not exhaustive, it’s meant to be high level and educational.

Congrats, you just watched authentication happen

Put it together and that login flow makes sense now. You POST your username and password to the server, the server checks them, and if they’re good it responds with a token. From then on, that token rides along with your requests so the server knows it’s you. When the token expires, you get kicked back to the login screen. That’s authentication.

The part you should not vibe code

Now, there are all sorts of nuances and subtleties to this that I can’t possibly cover in a blog post. And seeing how it works was hopefully cool and also enough detail to realize that it’s probably not something you want to vibe code.. that’s why I let existing third parties handle all of that stuff for me. A few examples of known auth providers are Auth0, Firebase auth, and Supabase. They generate the token and validate it, I just have to create the REST APIs that allow the data to flow. I can write some basic code examples if people are interested in seeing them. The flow is essentially:

  1. User clicks login with username and password
  2. Your app makes a REST API call to the auth provider
  3. All requests made to your app in the future should include a token
  4. Before you do anything, you ask the auth provider “does this token match the user?”, if so, you’re good to go!

Thanks for reading! I love writing and talking about this stuff. Feel free to ask other questions and suggest future topics or deep dives. I’m thinking perhaps Authorization and common security vulnerabilities for future posts but people have also expressed interest in application monitoring and analytics. Just let me know! Happy Friday and keep on vibin’!

-Adam