AI App Auth and Authorisation Check Before Launch

A login screen does not prove your AI-built app is protecting data. Authentication confirms who someone is. Authorisation decides what that person is allowed to see or do. Before launch, you need both. If an app lets users sign in but still allows the wrong records, admin pages, API routes or actions, it is not ready for real users.

Authentication versus authorisation

Authentication is the identity step: a user signs in with email, password, magic link, OAuth or another provider. Authorisation is the permission step: the app checks whether that signed-in user can view a page, update a record, access a team, manage billing or perform an admin action. AI-generated apps often implement the first step and assume the second is handled automatically.

That assumption is risky. The provider may confirm the user is logged in, but your app still has to enforce ownership, roles and route protection. A practical AI app security check looks at both identity and permission flow.

Why login is not enough

A user can be genuinely logged in and still reach the wrong data if the app trusts client-side filters, predictable IDs, open database policies or API routes that do not verify ownership. The interface may hide a button, but a route or request can still exist. The app may redirect anonymous visitors, but allow signed-in users to request any record by changing an ID.

This is why testing must include real journeys, direct URLs, refreshes, API calls triggered by the UI and multiple user accounts. A single demo account can make weak authorisation invisible.

Protected routes and server-side checks

Protected routes should be protected where the decision actually matters. Client-side route guards can improve user experience, but sensitive data and actions need server-side checks, database rules or both. If a page loads private data before redirecting, or an API route returns data before checking the user, the app can leak information even though the interface eventually moves away.

For AI-built apps using server functions or API routes, review whether each route verifies the current user and the requested resource. If live API behaviour differs from local testing, the issue may overlap with API calls working locally but not live.

User roles and ownership

Roles add another layer. A customer, team member, owner, admin and support user may all need different access. The app should not rely on a label in the browser to decide who is an admin. Role checks should happen in trusted code or database policies, and the app should have a clear model for which role can perform each action.

Ownership matters even without formal roles. A user should usually be able to read and edit their own records, not every record in the table. If generated code filters records after fetching them all, the app may already have exposed too much data to the browser.

Auth callback and redirect problems

Auth problems are not always security problems, but they can become one when developers loosen checks to make sign-in work. Callback URLs, redirect settings, session persistence, token refresh and deployment domains should match the live environment. If preview works but production does not, do not solve it by removing route protection.

Collect safe evidence: provider name, redirect URL, route, browser error, server error and whether the problem happens locally, in preview or live. Avoid sharing tokens, session cookies or private user data in AI tools.

What to test before launch

Create at least two normal user accounts and, if relevant, one admin account. Confirm each user can see only their own records. Try direct links to another user’s record if you have a safe test setup. Test refreshes, logged-out access, expired sessions, role changes, admin pages, billing pages, form submissions and API-backed actions. Check whether the browser network tab receives data that the current user should not see.

If Supabase is part of the stack, pair this with a Supabase RLS check. Auth and database rules should support each other rather than leaving one layer to carry all the risk.

What not to change blindly

Do not remove route guards because a redirect is annoying. Do not disable database policies to get past a permission error. Do not trust a hidden button as the only protection. Do not paste session tokens, cookies, user records or auth provider secrets into AI chats. If AI suggests broad changes to auth files without understanding the live app, pause.

Auth code can be fragile because it touches routing, provider settings, server functions, cookies, database users and UI state. Blind prompting can break working sign-in while still not fixing authorisation.

Review session and account edge cases

Also check edge cases that are easy to miss in a quick demo. What happens when a user signs out in one tab, changes email address, accepts an invite, loses a role, resets a password or returns after a session expires? AI-generated apps often handle the happy path but forget these transitions. That can leave protected screens in a confused state or keep old permissions alive longer than intended.

Use safe test accounts and redacted data for this review. You are not trying to break into anything. You are confirming that the app behaves consistently when identity, session state and permissions change in realistic ways.

Auth and authorisation checklist

• Confirm authentication works on the live domain, not only in preview.
• Test protected pages while logged out, logged in and using different roles.
• Check server-side verification for sensitive API routes and actions.
• Confirm users can access only their own records or permitted team records.
• Check whether client-side filtering is hiding data after it has already loaded.
• Review admin routes, billing actions, uploads and account settings.
• Check database policies where user-owned data is stored.
• Collect errors safely without sharing tokens or private data in AI tools.

When to stop prompting AI

Stop prompting AI when each auth fix creates a new redirect loop, breaks sessions, exposes more data or changes unrelated files. Stop if you cannot explain whether the app is checking identity, ownership or role at the right layer. At that point, a proper diagnosis is safer than another broad prompt.

If private data may already be visible to the wrong users, read the user data exposure guide and pause launch until the access model is reviewed.

Short conclusion

Auth is not finished when the login button works. An AI-built app needs identity, route protection, server-side checks, database rules and user permissions working together before real users rely on it.