Never Let AI Build Your Authentication From Scratch

Imagine you ask AI to add user accounts to your application.

A few minutes later, you have a login page, a registration form and maybe even a forgotten-password link. You create an account, log out, log back in and everything appears (appears is the key word) to work.

At this point, it is very tempting to consider authentication finished. The AI will probably be rather confident (more likely it will say it followed all latest best practices and your whole project has enterprise grade security) about it too.

Unfortunately, the login page is the easy part.

What you are actually asking it to build

Authentication is everything your application needs to reliably confirm that a user is who they claim to be.

Depending on the application, that can include:

• storing passwords securely
• creating and invalidating sessions
• managing cookies or access tokens
• verifying email addresses
• resetting forgotten passwords
• supporting multi-factor authentication
• limiting repeated login attempts
• protecting against known security attacks
• handling account recovery without giving access to the wrong person

A mistake in any of these areas can expose user accounts or private data.

What makes this especially dangerous is that bad authentication does not necessarily look broken. The login form can work perfectly while the implementation behind it is insecure.

Unless you know what to look for, you may never notice.

I have reviewed several vibe-coded applications featuring auth - most of them had passwords stored as plain text in the database in the best case or hard-coded on the frontend in some config file in the worst. From cyber security standpoint it’s hard to even imagine bigger red flags.

Use something boring and trusted

There are established services built specifically to handle authentication, such as Clerk, Auth0, Supabase Auth and Firebase Authentication.

I most often use Clerk. It is straightforward to integrate, has a very generous free tier and provides ready-made components for common flows such as registration, login and user account management.

More importantly for people building with AI, Clerk provides official prompts and instructions for AI coding tools. You can give those instructions directly to tools such as Claude Code, Cursor, Codex or GitHub Copilot instead of hoping they remember the correct integration from their training data.

This does not mean Clerk is the right choice for every project. The important part is using an established authentication provider rather than letting AI improvise its own solution inside your application.

Authentication is one of those areas where boring is good.

AI can still do the work

Using an authentication provider does not mean you need to set everything up manually.

AI can still:

• install and configure the provider
• add login and registration screens
• connect users to your application
• protect pages intended for logged-in users
• add logout and account-management controls
• test the different authentication states

The difference is that AI is integrating a system designed and maintained by authentication specialists. It is not inventing password storage, session handling and account recovery as it goes.

You are still getting the speed of AI-generated development, just without needlessly taking ownership of some very sensitive security logic.

A prompt you can reuse

Before asking AI to add authentication, give it instructions similar to these:

Do not create a custom authentication system or implement password storage,
session management, email verification, password recovery or other
security-sensitive authentication logic from scratch.

Use Clerk for authentication and follow its current official documentation
and AI integration instructions.

Before making changes, explain the proposed authentication flow and identify
which pages, server routes and data need to be protected.

Authentication must be enforced on the server where protected data is
accessed. Do not rely only on hiding pages, buttons or other interface
elements from logged-out users.

Keep secret keys in server-side environment variables. Never expose them in
browser code or commit them to the repository.

When finished, verify registration, login, logout and access by a logged-out
user. Run the relevant checks before creating a separate Git commit for the
authentication work.

Replace Clerk with another established provider if there is a good reason to use one. Just make sure AI follows that provider’s current documentation.

AI models regularly remember older versions of libraries and implementation patterns, so “use Clerk” alone is not always enough. Pointing the AI to current instructions significantly reduces the chance of it producing an outdated setup.

One more thing to check

Even when the authentication provider is secure, AI can still make mistakes when deciding what each user is allowed to access.

Being able to sign in is authentication. Being allowed to view or change a particular piece of data is authorization. They are related, but they are not the same thing.

We will look at that separately because it deserves its own article.

For now, remember that a working login page only proves that the login page works. It does not prove that the system behind it is secure.

Let AI integrate authentication for you. Just do not let it invent authentication for you.