Database Authentication & Row-Level Security (RLS)

NoCodeBackend features a built-in, native authentication engine (powered by Better Auth) that can be provisioned into any database with a single click. When enabled, your database automatically handles user registration, secure password hashing, social logins, session management, and strict Row-Level Security (RLS) so your users can only access their own data.

1. Overview: How Database Auth Works

In standard database setups, building authentication requires writing custom password salting, session cookies, JWT token issuance, password resets, and complex SQL filtering to prevent users from viewing each other's data.

NoCodeBackend eliminates all of this boilerplate:

• Instant System Tables: Enabling authentication automatically provisions three dedicated auth tables in your database: ncba_user, ncba_session, and ncba_account.
• Automatic User Linkage: Tables you designate automatically receive an indexed user_id foreign key referencing the authenticated user.
• Native Row-Level Security (RLS): When a client queries your REST API using a user session token, NoCodeBackend automatically injects WHERE user_id = session.user.id into every SQL query.

2. Authentication Methods & Providers

NoCodeBackend supports multiple flexible sign-in methods for your end users:

1. Email & Password:
   • Secure account registration with Argon2 / bcrypt password hashing.
   • Built-in password reset flows and verification emails.
2. Magic Links (Passwordless):
   • Users enter their email and receive a secure, time-limited one-click sign-in link.
3. Social OAuth Providers:
   • Google Sign-In: Authenticate users via Google OAuth 2.0.
   • GitHub: Ideal for developer tools and technical platforms.
   • Apple Sign-In: Required for iOS App Store compliance.

3. Step-by-Step Guide: Enabling Database Auth

Step 3.1: Turn On Authentication

1. Go to your NoCodeBackend Dashboard → My databases.
2. Click the database card you want to configure, and navigate to Authentication (or /databases/<your-database>/auth).
3. Toggle Enable Database Authentication to ON.
4. NoCodeBackend will execute the schema migration to provision:
   • ncba_user: Stores user profile data (id, email, name, image, created_at).
   • ncba_session: Manages active user sessions, expiration timestamps, and device tokens.
   • ncba_account: Links OAuth providers and account IDs.

Step 3.2: Configure OAuth Providers (Optional)

If you want to allow Google or GitHub sign-ins:

1. In the OAuth Providers tab, select the provider (e.g., Google).
2. Enter your Client ID and Client Secret (from the Google Cloud Console).
3. Copy the provided Redirect URI from NoCodeBackend and paste it into your Google OAuth authorized redirect URIs.
4. Click Save Provider.

4. Row-Level Security (RLS): How Access Is Enforced

Row-Level Security ensures complete multi-tenant data isolation. It guarantees that user Alice can never view, edit, or delete data belonging to user Bob.

How RLS Works Under the Hood:

When a client application queries your data via the /api/data/* proxy:

1. Reads (GET /api/data/read/<table_name>?Instance=<db>):

   • The API verifies the active user session cookie (better-auth.session_token) or Bearer session token.
   • The query engine automatically rewrites the SQL query:
     SELECT * FROM tasks WHERE user_id = 'user_abc123'
     

   • Even if the client queries without filters, they will only ever receive rows where user_id matches their verified session ID.

2. Single-Record Reads (GET /api/data/read/<table_name>/:id?Instance=<db>):

   • The query enforces ownership:
     SELECT * FROM tasks WHERE id = ? AND user_id = 'user_abc123'
     

   • If an unauthenticated user or another user requests this ID, the API returns 404 Not Found.

3. Creates (POST /api/data/create/<table_name>?Instance=<db>):

   • The client does not need to send user_id in the JSON body.
   • The API automatically injects user_id = session.user.id into the record before writing to the database, preventing user spoofing.

4. Updates & Deletes (PUT / DELETE /api/data/update|delete/<table_name>/:id?Instance=<db>):

   • The query verifies that the targeted row belongs to the requesting user:
     UPDATE tasks SET title = ? WHERE id = ? AND user_id = 'user_abc123'
     

   • If a malicious user guesses another record's ID and sends an update or delete request, the API rejects it with 404 Not Found or 403 Forbidden.

5. Built-in Session Auth vs Server Secret Keys

| Feature | Built-in Session Auth | Database Secret Key | | :--- | :--- | :--- | | Intended Environment | Frontend clients (React, Next.js, mobile) | Secure backends (Node.js, Server Actions, Python) | | Security Scope | Scoped strictly to authenticated end user | Database administrative access | | Row-Level Security | Strictly Enforced (WHERE user_id = session.id) | Bypasses RLS (Can access all records) | | Authentication | Session cookies (better-auth.session_token) | Authorization: Bearer ncb_sec_... | | Client Safe? | ✅ Yes, designed for client portals | ❌ Never expose in client bundles |

6. Frontend Integration

Option A: Pre-Built React UI (@nocodebackend/account-react)

The fastest way to add authentication, user profile management, and account settings is with our official React package:

npm install @nocodebackend/account-react@latest

import { NCBAuthProvider, NCBAccount } from "@nocodebackend/account-react";

export default function App() {
  return (
    <NCBAuthProvider dbInstance="your_database_instance">
      <NCBAccount />
    </NCBAuthProvider>
  );
}

This drop-in component provides:

• Login & Registration modals (Email/password and OAuth).
• Password reset and email confirmation.
• User profile updates (name, avatar, change password).
• Active device and session management with one-click revocation.
• Live monetization and billing portal access.

Option B: Data Proxy API

In customer portals (such as Next.js applications), route client requests through your application's data proxy (/api/data/[...path]), which forwards user session cookies to NoCodeBackend:

// Query current user's records with automatic RLS
const res = await fetch("/api/data/read/tasks?Instance=your_database", {
  method: "GET",
  credentials: "include" // includes session cookies
});

const data = await res.json();

7. Troubleshooting

Common Errors

Error: 403 Forbidden: User not authorized to access this record

• Cause: The active session token's user_id does not match the user_id on the requested row.
• Resolution: This is the expected behavior of Row-Level Security. Ensure your frontend is requesting records created by the logged-in user.

Error: OAuth redirect_uri_mismatch

• Cause: The redirect URI registered in your Google or GitHub developer console does not match the URI generated by NoCodeBackend.
• Resolution: Go to /databases/<your-database>/auth, copy the exact Redirect URI, and paste it into your OAuth provider console without trailing slashes.