Authentication is how your app confirms someone is who they say, usually by checking a password or a login with Google or Apple. Once confirmed, the app remembers them for a while so they need not log in on every page. Done well it protects accounts; done carelessly, it is where some of the most serious app holes appear.
Information current as at 5 July 2026
The moment your app has accounts, it has to answer a deceptively hard question: is this person really who they claim to be. That is authentication, and it sits behind every login. Understanding roughly how it works, and where it commonly goes wrong, is important, because logins are one of the areas AI-built apps most often get subtly unsafe.
Authentication is the app's way of confirming identity: making sure the person in front of it is genuinely who they claim to be before letting them into an account. In everyday terms it is the login. The most familiar form is a password: you registered one, and each time you return the app checks that what you type matches. Increasingly common is logging in through another service you already trust, like Google or Apple, where that service vouches for who you are and hands your app a confirmation, so your app never handles a password at all. Either way, the goal is the same: to establish, with reasonable confidence, that this is the right person, so that your account and your data are shown to you and not to a stranger. Every app with accounts does this at the front door, and the quality of how it does it is one of the truest measures of whether the app is actually safe.
When you type a password, a well-built app does not simply compare it to a stored copy, because storing real passwords is dangerous; if the database leaked, every password would leak with it. Instead it uses hashing: the password is scrambled by a one-way process into a jumble that cannot be reversed, and only that jumble is stored. At login, your typed password is scrambled the same way and the two jumbles are compared. The app can confirm you know the password without ever keeping the password itself. Once you are confirmed, the app gives your browser a kind of temporary pass, a session, so you are remembered as logged in for a while and do not have to prove yourself again on every single page. That session eventually expires or is cleared when you log out. This quiet machinery, hashing at the door and a session afterwards, is what a sound login is made of, whether you see it or not.
If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.
There is a distinction here that matters enormously and is easy to miss. Authentication answers who are you. Authorisation answers what are you allowed to do. They are different, and confusing them is behind a whole class of app failures. An app can correctly confirm who you are, then fail to properly limit what you can reach, so that a logged-in user can see or change things that should not be theirs, another customer's records, an admin page, data from behind the scenes. Confirming identity is only half the job; enforcing limits on each confirmed identity is the other half, and it has to happen in the backend where the visitor cannot bypass it. A frighteningly common pattern in AI-built apps is decent authentication paired with weak or missing authorisation, so people can log in fine but then reach far more than they should. Both halves have to be right for an app to be genuinely safe.
Because login handling is intricate, it is where AI-built apps often develop quiet, serious holes. A few patterns recur. Passwords stored without proper hashing, so a leak exposes them all. Authorisation enforced only in the frontend, where a determined visitor can walk straight around it, rather than in the backend. Data access rules, like the Row Level Security a database such as Supabase offers, left open, so any logged-in user can pull other people's records. Or reliance on a login screen that looks convincing while the backend does not actually check anything. The unsettling part is that none of this is visible from using the app; it logs you in, it looks professional, and the hole stays hidden until someone finds it. If your app has accounts and holds anything about your users, how its authentication and authorisation are actually built is precisely the kind of thing worth having a knowledgeable pair of eyes confirm before real customers rely on it.
If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.
Whether you can name exactly what you want built, or you just know something is leaking, the next step is the same conversation.