How to Add Authentication to an AI-Generated App Safely

List the supported users, sign-in methods, verified attributes, roles, organizations, invitation rules, and administrator capabilities. Decide what happens when an email changes, an employee leaves an organization, an account is suspended, or two login methods resolve to the same address. These are data-model decisions, not finishing touches.

Define recovery and deletion early. Password reset, lost second factors, expired invitations, and account closure are high-risk workflows that attackers target. Specify whether data is deleted, anonymized, transferred, or retained, and which privileged actions require recent authentication.

Compare provider or library support for your framework, server runtime, mobile or API clients, required identity protocols, multi-factor authentication, audit events, data residency, pricing, and exportability. Verify callback and logout behavior rather than selecting from a generated integration snippet alone.

If using passwords, rely on a maintained authentication system for password hashing, breach-resistant controls, reset tokens, and session invalidation. Do not design custom cryptography or store recoverable passwords. For OAuth or OpenID Connect, use established libraries with state, nonce, PKCE where applicable, and strict redirect URI validation.

For browser applications, server-managed sessions in Secure, HttpOnly, appropriately scoped SameSite cookies are often a sound default. Other clients may require short-lived bearer tokens and carefully protected refresh tokens. The correct pattern depends on architecture, but tokens should not be placed in URLs or exposed through logs and analytics.

Rotate session identifiers after login and privilege changes, define idle and absolute expiry, and revoke sessions after password reset, account disablement, or suspected compromise. If cookie authentication is used, ensure state-changing requests receive suitable CSRF protection. Restrict CORS to expected origins and credentials behavior.

Authentication provides a verified identity; it does not answer whether that identity may read a particular invoice or manage another user. Implement authorization in server-side routes, actions, jobs, file delivery, and database queries. Scope records by ownership or tenant and express privileged capabilities in centralized policies.

Do not accept role, organization, or user identifiers from the client as proof. Derive them from the validated session and trusted application records. If using database row policies, test them with the same credentials and access paths used by production code, including service credentials that may bypass policies.

Return neutral responses for login and recovery where account enumeration would create risk. Rate-limit by a combination of account, network, device, and behavior as appropriate, while avoiding controls that let an attacker lock out a victim. Use single-use, short-lived verification and reset tokens and invalidate them after relevant account changes.

Invitations need the same care as password resets: bind them to intended context, expire them, prevent replay, and display what organization or role will be joined. Require stronger verification for changing email, adding authenticators, exporting data, or performing high-impact administrative actions.

Store the provider's stable subject identifier as the external identity key rather than using a mutable email as the primary link. Keep application profile data and authorization state in a model you control. Process identity webhooks idempotently and do not assume they arrive once or in order.

Plan migration for existing anonymous or prototype records. Linking data based only on a newly entered email can expose another person's records. Use a verified claim, signed invitation, existing authenticated session, or deliberate support process to establish ownership.

Automate tests for login, logout, expiry, recovery, callback rejection, session revocation, and each authorization boundary. Manually test multiple tabs, back-button behavior, changed roles, provider errors, and direct API requests. Confirm private pages do not leak through caches or pre-rendered assets.

Monitor authentication failures, unusual recovery volume, privilege changes, new authenticator enrollment, and provider webhook failures. Keep runbooks for provider outages, credential rotation, account suspension, and user-reported compromise. Support staff should have narrowly scoped tools rather than direct database access.