You're in. Let's build something secure.

Welcome to Supabase Auth & RLS for Unity 2D Platformers — the only course that teaches you production-grade authentication and row-level security while building an actual game.

Here's how to get the most out of this:

1. Start Module 1 immediately — the project setup takes ~30 minutes and everything builds on it

2. Follow the modules in order — each lesson unlocks the next, and later modules reference earlier code

3. Use the Community Chat — post questions, share progress, help others. The fastest learners here are the ones who engage

4. Ship your final project — Module 6 walks you through a full RLS audit and multi-platform build. Completers earn a certificate

What you'll walk away with:

• A fully playable Unity 2D platformer with coin collection, cloud saves, and real-time leaderboards

• Production-ready Supabase Auth (email/password, Google, Discord, Apple)

• Row Level Security policies you actually understand — not just copy-pasted from docs

• A deployment-ready game with proper security across platforms

No fluff. No filler. Every lesson has code you'll use in the final build.

Let's get to work. See you in Module 1.

— AuthLock Academy

If you're building any Unity game with online features — leaderboards, cloud saves, user accounts — and you're not using Row Level Security, your data is exposed. Here's why.

The Problem

Most indie devs connect their Unity client directly to a backend (Firebase, Supabase, custom API) and rely on client-side checks to protect data. This is fundamentally broken.

A player with basic tools can:

• Modify their own leaderboard scores

• Read other players' save data

• Delete records they shouldn't have access to

• Impersonate other users

Client-side validation is not security. It's a suggestion.

What Row Level Security (RLS) Actually Does

RLS moves your access rules into the database itself. Every query — SELECT, INSERT, UPDATE, DELETE — is filtered through policies you define at the Postgres level.

Here's a real example. Say you have a player_scores table:

-- Players can only read their own scores
CREATE POLICY "Players read own scores"
ON player_scores FOR SELECT
USING (auth.uid() = player_id);

-- Players can insert scores, but only for themselves
CREATE POLICY "Players insert own scores"
ON player_scores FOR INSERT
WITH CHECK (auth.uid() = player_id);

Now it doesn't matter what the client sends. A player literally cannot query another player's data. The database rejects it before the query runs.

Why Supabase + Unity Is the Best Stack for This

Supabase gives you Postgres with RLS built in, plus a full auth system (email, Google, Discord, Apple) — all with a REST API that Unity can call directly.

No custom backend server. No cloud functions for basic CRUD. Just:

1. Authenticate the user (Supabase Auth)

2. Make database calls from Unity (Supabase REST)

3. Let RLS enforce every rule at the database layer

The 3 Policies Every Unity Game Needs

1. Auth-gated reads — users can only SELECT rows where player_id = auth.uid()

2. Scoped inserts — users can only INSERT rows tagged with their own ID

3. Admin overrides — service-role keys bypass RLS for server-side operations (leaderboard aggregation, moderation)

Want to Go Deeper?

Inside AuthLock Academy, I walk through building a complete Unity 2D platformer with Supabase Auth, cloud-synced coin collection, real-time leaderboards, and full RLS policies — from zero to deployed.

6 modules. 15 lessons. You ship a real game at the end.

If you're serious about building multiplayer Unity games that don't get wrecked on day one, this is the course.