Tom Hundley
🤖 Ghostwritten by Claude Opus 4.6 · Fact-checked & edited by GPT 5.4
The safest password for your app is the one your app never handles. That is the core advantage of OAuth and managed sign-in options like "Login with Google," "Sign in with Apple," or GitHub login. Instead of collecting usernames and passwords yourself, you send users to a provider that already knows how to verify identity, detect suspicious sign-ins, and protect account recovery. Your app gets back proof that the user is authenticated. It does not need to store the password at all.
That matters because authentication is one of the most commonly skipped basics in vibe-coded apps. The RedAccess "Shadow Builders" report, disclosed on 2026-05-07 and 2026-05-08, found roughly 5,000 of about 380,000 scanned vibe-coded apps with no authentication at all, and about 40% of those were leaking sensitive data. The lesson is straightforward: building login yourself is easy to underestimate and easy to get dangerously wrong. OAuth does not eliminate risk, but it dramatically reduces how much can go wrong.
TL;DR: OAuth lets a trusted provider verify the user so your app does not have to collect or store the user's password.
In plain English, OAuth is a delegation system. When someone clicks "Login with Google," your app is not asking Google to hand over the user's password. It is asking Google to confirm the user's identity and return a token your app can trust.
A simple flow looks like this:
The practical benefit is huge: your application never needs to store a password database for those users. That removes one of the highest-risk parts of authentication.
A useful mental model is a hotel check-in desk. The guest shows ID to the concierge, not to you. The concierge verifies the person, then tells you they are approved for a room. You act on that approval. You do not photocopy the ID or keep a file of sensitive documents.
TL;DR: A custom username-and-password system only looks simple; in practice, it requires many security controls that are easy to miss.
A basic login form is easy to generate. A secure authentication system is not. The difference is everything around the happy path.
| Requirement | What it means | What goes wrong if skipped |
|---|---|---|
| Password hashing | Storing passwords as one-way hashes with bcrypt, Argon2, or scrypt | A breach can expose usable passwords if they were stored improperly |
| Rate limiting | Slowing or blocking repeated failed sign-in attempts | Attackers can brute-force accounts |
| Reset flow security | Using single-use, time-limited reset links sent to verified email | Attackers can hijack accounts through weak recovery flows |
| Session management | Issuing secure, expiring sessions after login | Stolen or long-lived sessions can be abused |
| Breach response | Detecting compromise and forcing resets or revocations when needed | Compromised accounts can remain exposed |
This is where AI-generated auth code often falls short. It may produce a working login screen and database table, but skip the controls that make the system safe under attack.
The RedAccess findings reinforce the point. Thousands of scanned vibe-coded apps had no authentication at all, and a significant share of those exposed sensitive data. Even when authentication exists, weak implementation can still create serious risk.
If a custom login already exists, the first question should be simple: are passwords hashed correctly?
They should never be stored in plaintext. They also should not rely on weak legacy approaches such as MD5 or SHA-1 alone for password storage. Modern password hashing functions such as bcrypt, Argon2, or scrypt are designed to make password cracking slower and more expensive.
That does not make a breach harmless, but it can make the difference between a contained incident and immediate account takeover across every user who reused the same password elsewhere.
TL;DR: OAuth removes the burden of password handling, but you still have to configure it correctly and protect the tokens it returns.
OAuth and managed authentication reduce risk by shrinking the number of security problems your app has to solve. They do not remove every security responsibility.
There are still several things to get right:
That is the balanced framing: OAuth is not magic. It is simply a much better default than building password authentication from scratch, especially for small teams and non-developers.
TL;DR: Use managed auth by default, and if a custom login already exists, harden it immediately.
If the app is still early, use a managed authentication provider or add OAuth through a service that handles the hard parts for you. Common options include Supabase Auth, Firebase Authentication, Auth0, and Clerk.
The main benefit is not convenience alone. It is that these systems already handle password storage, session controls, provider integrations, and many common abuse protections.
If replacing the login system is not practical yet, start with the highest-value fixes:
Those steps do not make a custom system perfect, but they reduce the chance of an avoidable failure.
This is a separate issue from OAuth, but it still matters. Turn on two-factor authentication for the accounts that control your app, including source control, hosting, domain registration, and email. If one of those accounts is compromised, an attacker may be able to change the app directly regardless of how user login works.
TL;DR: If AI helped build the login flow, use AI again to audit the security basics before shipping.
Paste this into your coding assistant:
Review how this app handles user login and authentication. Specifically:
1. Does the app store user passwords? If so, what hashing algorithm is used
(bcrypt, Argon2, scrypt, or something weaker like MD5/SHA-1/plain text)?
2. Is there rate limiting on login attempts? What are the thresholds?
3. How are password reset tokens generated, and do they expire?
4. Are session tokens stored securely?
5. Is there any brute-force protection beyond rate limiting?
Then recommend a migration plan to switch to a managed auth provider
(such as Supabase Auth, Firebase Auth, Auth0, or Clerk) using OAuth
(Login with Google / Apple / GitHub). List exactly what I would need to
configure: redirect URIs, OAuth scopes, token storage, and session
management. Flag any sensitive data that would need to be migrated or
purged, such as existing plaintext or weakly hashed passwords.OAuth is a way for your app to rely on a trusted provider to verify identity instead of collecting and checking passwords itself. The user signs in with the provider, and your app receives proof that the user is authenticated.
For many apps, yes. The bigger question is user fit, not just security. If your audience may prefer Apple, GitHub, or email-based sign-in, offering more than one option can reduce friction. From a security perspective, a well-implemented provider login is often safer than a hand-built password system.
Not always. If replacing it now would be disruptive, harden it first: verify password hashing, add rate limiting, and review reset and session handling. Then plan a migration to managed auth when feasible.
No. OAuth or managed sign-in helps answer who the user is. Authorization is the separate question of what that user can access once signed in. Apps still need clear permission checks.
Treating it as set-and-forget infrastructure. The most common implementation mistakes are overbroad scopes, poorly controlled redirect URIs, and weak token handling.
For most new apps, especially vibe-coded projects, "Login with Google" is not just a convenience feature. It is a security decision. Delegating identity verification to providers that already operate hardened sign-in systems dramatically reduces the number of ways an app can fail.
That does not remove the need for careful implementation. Tokens still need protection, scopes still need restraint, and authorization still needs to be designed well. But compared with rolling your own password system, OAuth is usually the safer default by a wide margin.
Discover more content: