Guide

How to add authentication to an AI-built app

Authentication establishes who is using your app. Permissions decide which records they can see or change. Start by distinguishing a private team tool from a customer service with public registration, then test both boundaries.

Short answer

Use an established identity integration or a platform login gate suited to your users. Avoid inventing password and session handling. Enforce record permissions on the server, then test signed-out access and two accounts with different rights.

For a named team, a hosting platform’s access gate can avoid building a separate sign-in flow. For public customer accounts, use a maintained framework integration or identity provider that supports registration and account recovery. Operating an identity server yourself adds patching, availability and recovery responsibilities.

AppHaven’s private gate fits team-oriented AI-built business applications and admits project members. Vercel Deployment Protection can also restrict deployment access, subject to scope and plan. Neither replaces permissions inside the app. The following example uses AppHaven; the two-account tests apply to either approach.

Choose who the app is for

For an invoice tracker used by named colleagues, project membership is a straightforward access list. Nobody needs a separate password table inside the app just to get through the door.

A customer portal with public registration has a different requirement. Making an AppHaven app Public opens it to anonymous requests; it does not add customer accounts. Plan customer sign-up, account recovery and tenant permissions with an established identity service or framework integration. You can still host the portal and database on AppHaven.

Set up private access

Select Private in Settings
An administrator chooses the app’s access mode. Redeploy the branch after changing the setting so it takes effect.
Invite a colleague
Use the project’s Members page and give them the access they need. Someone using the app does not need permission to administer its hosting.
Test from a signed-out browser
Open both the app’s homepage and a protected API URL in a private browsing window. Both should lead to login before showing private content.
Remove a test member
Confirm that the removed member can no longer reach private apps in that project. This checks the departure process as well as the invitation process.

Requests that pass the gate carry an X-Apphaven-Auth identity header. Public requests do not. Use the current authentication reference linked from AppHaven’s access documentation for its exact format; do not guess its encoding or fields.

Ask your agent to put identity handling in one server-side adapter and return no user when the identity is missing or invalid. The adapter should map the verified identity to a stable application user ID. Only trust this header behind AppHaven’s gateway; a local client can invent a header if you expose the server directly.

Check permissions where the data is used

Permission flow, pseudocode

user = read_verified_apphaven_identity(request)
if user is missing:
    return 401

invoice = find_invoice(request.invoice_id)
if invoice is missing or not can_view_invoice(user, invoice):
    return 404

if request changes the invoice and not can_edit_invoice(user, invoice):
    return 403

perform the permitted action

This illustrates the application logic, not a copy-paste authentication library. Implement the identity adapter from the platform contract and enforce these checks on the server.

Verify with two accounts

Test	Expected result
Alice opens an invoice she may view	The invoice is shown.
Bob requests that invoice without permission	The server returns no invoice contents.
Bob sends an edit request directly to the API	The server rejects it; hiding an Edit button alone is insufficient.
A signed-out visitor opens the private endpoint	The platform asks them to sign in.
A public request includes an invented identity header	It must not become an authenticated application user.

Open webhooks deliberately

A payment provider cannot use your colleague’s browser login. If it needs a webhook, an administrator can exempt the specific callback path and redeploy. Your server must verify the provider’s signature and handle duplicate deliveries on that route.

Keep the exemption narrow. Opening /api/* to make one callback work also opens unrelated API routes. Test that the webhook accepts a valid signed request, rejects an invalid one, and that the neighbouring invoice endpoint still requires login.

Keep account access separate from record access

A login gate stops anonymous visitors from reaching private code. It does not stop an authorised colleague from exploiting a missing record check, and it does not make request validation unnecessary. Keep the two-account tests in the project so future changes do not silently remove the permissions you established.

Common questions

Can everyone in a private app see everything?

Project membership permits entry to the app. The application decides which records and actions each person may access. If all members should share the same view, make that an explicit business decision.

Do public pages receive a signed-in identity?

A path that skips the gate has no AppHaven identity header. Treat it as anonymous and authenticate the request separately when the endpoint requires it.

Give your team a private app

If project-member access fits your users, try AppHaven’s private gate alongside the permission tests in this guide.

Try it with your app Read the docs

Choose the right kind of sign-in