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 REST API:

1. Reads (GET /api/v1/<db>/<table_name>):

   • The API verifies the user's JWT from the Authorization: Bearer <user_jwt> header.
   • The query engine automatically rewrites the SQL query:
     SELECT * FROM tasks WHERE user_id = 'user_abc123'
     

   • Even if the client attempts to query GET /tasks, they will only ever receive rows where user_id matches their verified session ID.

2. Creates (POST /api/v1/<db>/<table_name>):

   • 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.

3. Updates & Deletes (PATCH / DELETE /api/v1/<db>/<table_name>/:id):

   • 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 a DELETE or PATCH request, the API rejects it with 403 Forbidden or 404 Not Found.

5. Client-Side JWTs vs Server Secret Keys

| Feature | Database Auth JWT | Database Secret Key (x-api-key) | | :--- | :--- | :--- | | Intended Environment | Frontend clients (React, Vue, iOS, Android) | Secure backends (Node.js, Next.js API, Python) | | Security Scope | Scoped to individual authenticated end user | Full database administrative access | | Row-Level Security | Strictly Enforced (WHERE user_id = session.id) | Bypasses RLS (Can access all records) | | Header Name | Authorization: Bearer <jwt_token> | x-api-key: ncb_sec_... | | Client Safe? | ✅ Yes, designed for public apps | ❌ Never expose in client bundles |

6. Frontend Integration

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

The fastest way to add authentication and user profile management 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.
• Profile settings (name, avatar, change password).
• Seamless token persistence in localStorage and cookies.

Option B: Direct REST API

If you are building a custom UI or native mobile app, call the authentication endpoints directly:

// Register a new user
const res = await fetch("https://api.nocodebackend.com/v1/your_database/auth/sign-up/email", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    email: "user@example.com",
    password: "SecurePassword123!",
    name: "Alex Doe"
  })
});

const { token, user } = await res.json();

// Make an authenticated RLS query
const tasksRes = await fetch("https://api.nocodebackend.com/v1/your_database/tasks", {
  headers: {
    "Authorization": `Bearer ${token}`
  }
});

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.