Skip to main content
Practical How-To Architecture & Scale 5 min read

How to Add Authentication and Authorisation to a Vibe-Coded App

July 2026

When to use this: Your app has some form of login already, or you're about to add one — and you're not confident that being logged in actually restricts what a user can see and do to only their own data.

Why this matters

Authentication and authorisation are two different problems, and AI-generated code is much better at the first than the second. Authentication answers "who is this person" — a login screen, a session, a token. Authorisation answers "what is this specific person allowed to do" — and specifically, whether the data they're requesting actually belongs to them.

It's entirely possible to have working login and still let any logged-in user pull up any other user's data, simply by changing an ID in a request. That gap — checking that someone is logged in without checking that this logged-in user owns this resource — is one of the most common real vulnerabilities in fast-built apps, and it's invisible in a demo because you're always testing with your own account.

1

Separate authentication from authorisation before you touch any code

Authentication: is this a real, logged-in session? Authorisation: does this specific user have permission for this specific action on this specific resource? Most gaps come from solving only the first and assuming the second follows automatically. It doesn't.

2

Audit every endpoint that returns or changes data

For each one, ask: does this check that the request is for a resource the logged-in user actually owns, or does it only check that some valid session exists? An endpoint like "get order details" that checks for a valid session but not that the order belongs to that session is the single most common gap to find.

3

Use short-lived sessions or tokens with real expiry

A token that never expires is a permanent open door if it's ever leaked. Set an expiry, and have a clear process for refreshing it, rather than issuing something that's valid indefinitely.

4

Never store or log plaintext passwords

If you're managing your own authentication, passwords need to be hashed with a strong, purpose-built algorithm before they're stored — and they should never end up in application logs, error reports, or debugging output.

5

Consider using an established identity provider instead of building auth from scratch

Authentication looks simple until you hit the edge cases — password reset flows, session fixation, account enumeration, brute-force protection — all of which are easy to get subtly wrong under time pressure and have already been solved properly by providers who specialise in exactly this.

6

Add rate limiting on login and other sensitive endpoints

Without it, there's no friction stopping someone from brute-forcing credentials or hammering an expensive endpoint as many times as they like.

7

Test authorisation by deliberately trying to break it

Log in as one user and try to access another user's data on purpose — change an ID in a request, try an endpoint you shouldn't have access to. The only real way to know your authorisation checks work is to actively try to defeat them, not just confirm your own account works as expected.

Common mistakes

Treating "logged in" as the same thing as "authorised." A valid session proves identity. It doesn't prove permission for the specific thing being requested.

Building authentication from scratch under time pressure. The core login flow is easy. The edge cases — password reset, session handling, brute-force protection — are where fast-built auth quietly breaks, and they're exactly the parts that don't show up in a demo.

Only testing the happy path. Confirming a user can see their own data proves nothing about whether they can see someone else's. That negative test is the one that actually matters, and it's the one that almost never gets run.

Free Tool

Security Readiness Assessment — a fuller picture of your security posture beyond just auth

Run the assessment →

Continue reading

Not sure how deep the security gap goes? Run the Security Readiness Assessment →

TechTekGo Newsletter

AI engineering insights — from prototype to production.

No noise. Published when there's something worth reading.