Using auth.uid() in policies in Supabase - Deep Dive

Overview - Using auth.uid() in policies

What is it?

Using auth.uid() in policies means writing rules that check the unique ID of the user making a request. This ID helps control who can see or change data in a database. It is a way to keep data safe by making sure only the right people have access. These rules are part of the database's security system.

Why it matters

Without using auth.uid(), anyone could access or change data they shouldn't. This would be like leaving your house unlocked for strangers. Using auth.uid() ensures that only the owner or authorized users can access their data, protecting privacy and preventing mistakes or attacks.

Where it fits

Before learning this, you should understand basic database concepts and what user authentication means. After this, you can learn more advanced security policies, role-based access control, and how to combine multiple conditions for complex rules.

Mental Model

Core Idea

auth.uid() is the unique user ID that policies use to check if a user is allowed to access or modify data.

Think of it like...

It's like a keycard with your unique ID that you swipe to enter a building; the door only opens if the ID matches the allowed list.

┌───────────────┐
│   User sends  │
│  request with │
│   auth.uid()  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Policy checks │
│ if auth.uid() │
│ matches data  │
└──────┬────────┘
       │
   Yes │ No
       ▼    ▼
┌───────────┐  ┌───────────────┐
│ Allow     │  │ Deny access   │
│ access    │  │               │
└───────────┘  └───────────────┘

Build-Up - 6 Steps

1

Foundation

What is auth.uid() in Supabase

Concept: auth.uid() returns the unique ID of the currently logged-in user.

In Supabase, every user who logs in gets a unique identifier called uid. The function auth.uid() lets you get this ID inside your database policies. This ID is a string that never changes for that user.

Result

You can identify who is making a request by calling auth.uid() in your policy rules.

Understanding that auth.uid() represents the current user is the key to writing personalized access rules.

2

Foundation

Basics of Row-Level Security Policies

Concept: Policies control who can read or write each row in a table based on conditions.

Row-Level Security (RLS) lets you write rules that say who can see or change each row in a table. For example, you can say only the user who owns a row can read or update it. Policies use expressions that can include auth.uid() to check the user.

Result

You can protect data by limiting access to only authorized users at the row level.

Knowing that policies filter data per row helps you create fine-grained security.

3

Intermediate

Using auth.uid() to Match Owner Field

🤔Before reading on: do you think auth.uid() should be compared to a user ID field or a username field? Commit to your answer.

Concept: Policies often compare auth.uid() to a column that stores the owner's user ID.

A common pattern is to have a column like user_id in your table that stores the owner's uid. In your policy, you write: `using: (user_id = auth.uid())`. This means only the user whose uid matches user_id can access that row.

Result

Users can only access rows they own, preventing others from seeing or changing their data.

Matching auth.uid() to the owner field is the simplest and most secure way to enforce user-specific access.

4

Intermediate

Combining auth.uid() with Other Conditions

🤔Before reading on: can auth.uid() be used with other conditions like checking a status field? Commit to your answer.

Concept: You can combine auth.uid() checks with other filters to create complex policies.

For example, you might allow users to update their data only if a status column is 'pending'. The policy could be: `using: (user_id = auth.uid() AND status = 'pending')`. This means users can only update their own rows that are still pending.

Result

Policies become more flexible and precise, allowing different rules for different situations.

Combining auth.uid() with other conditions lets you tailor access rules to real-world workflows.

5

Advanced

Handling auth.uid() in Insert and Update Policies

🤔Before reading on: do you think auth.uid() is available in both insert and update policy expressions? Commit to your answer.

Concept: auth.uid() can be used in both insert and update policies but with different expressions: 'with check' and 'using'.

For inserts, you use 'with check' to ensure the new row's user_id matches auth.uid(). For updates, 'using' checks the existing row's user_id matches auth.uid(). Example insert policy: `with check: (user_id = auth.uid())`. Example update policy: `using: (user_id = auth.uid())`.

Result

Users can only create or modify rows that belong to them, preventing data spoofing.

Knowing the difference between 'using' and 'with check' with auth.uid() prevents common security holes.

6

Expert

Surprising Behavior with auth.uid() in Edge Cases

🤔Before reading on: do you think auth.uid() is always set during all database operations? Commit to your answer.

Concept: auth.uid() is only available when the request is authenticated; it is null for anonymous or service role calls.

If a request is made without authentication, auth.uid() returns null. This means policies using auth.uid() will deny access unless you explicitly allow null. Also, service role keys bypass RLS and ignore auth.uid(). Understanding these cases is crucial to avoid accidental data leaks or denials.

Result

You avoid unexpected access denials or leaks by handling null auth.uid() and service roles properly.

Knowing when auth.uid() is null or bypassed helps you write safe policies and debug access issues.

Under the Hood

When a user makes a request, Supabase verifies their identity and attaches their unique user ID (auth.uid()) to the request context. The database engine then evaluates the row-level security policies using this ID. Policies are SQL expressions that run inside the database, filtering rows or allowing actions only if the conditions involving auth.uid() are true.

Why designed this way?

This design keeps security checks close to the data, reducing the risk of bypassing rules. Using auth.uid() inside the database ensures that access control is consistent and cannot be altered by client-side code. It also leverages PostgreSQL's powerful policy system for fine-grained control.

┌───────────────┐
│ User Request  │
│ with auth.uid │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Supabase Auth │
│ verifies user │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Database RLS  │
│ evaluates     │
│ policies with │
│ auth.uid()    │
└──────┬────────┘
       │
   Yes │ No
       ▼    ▼
┌───────────┐  ┌───────────────┐
│ Allow     │  │ Deny access   │
│ operation │  │               │
└───────────┘  └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does auth.uid() return the user's email or username? Commit to your answer.

Common Belief: auth.uid() returns the user's email or username.

Reality: auth.uid() returns a unique identifier string, not email or username.

Why it matters: Using email or username instead of uid in policies can cause security holes or broken access because these fields can change or be duplicated.

Quick: Can auth.uid() be used in policies for anonymous users? Commit to your answer.

Common Belief: auth.uid() works for all users, including anonymous ones.

Reality: auth.uid() is null for anonymous users; policies relying on it will deny access unless handled explicitly.

Why it matters: Failing to handle null auth.uid() can block legitimate anonymous access or cause confusion.

Quick: Does the service role key respect auth.uid() policies? Commit to your answer.

Common Belief: Service role keys are checked against auth.uid() policies like normal users.

Reality: Service role keys bypass RLS and ignore auth.uid() policies entirely.

Why it matters: Misunderstanding this can lead to accidental data exposure if service role keys are leaked or misused.

Quick: Is it safe to trust client-side code to enforce auth.uid() checks? Commit to your answer.

Common Belief: Client-side code can safely enforce auth.uid() checks without database policies.

Reality: Client-side checks can be bypassed; only database policies using auth.uid() guarantee security.

Why it matters: Relying on client-side checks alone risks data leaks and unauthorized access.

Expert Zone

1

Policies using auth.uid() must consider that the uid is a string and comparisons are case-sensitive.

2

When combining multiple policies, the database uses OR logic between policies and AND logic within a policy, affecting how auth.uid() conditions combine.

3

Using auth.uid() in functions or views requires careful permission setup to avoid bypassing RLS.

When NOT to use

Do not rely on auth.uid() for access control in background jobs or service-to-service calls; instead, use service role keys with strict permissions. For public data, use policies that allow access without auth.uid().

Production Patterns

In production, auth.uid() is used to enforce user ownership of data, combined with role checks for admins. Policies often include expiration or status fields to limit access over time. Monitoring and logging policy denials help detect misconfigurations.

Connections

Role-Based Access Control (RBAC)

auth.uid() policies build on RBAC by adding user-specific row filtering.

Understanding RBAC helps grasp how auth.uid() fits into broader access control strategies.

OAuth Authentication

auth.uid() depends on OAuth or other auth systems to provide the unique user ID.

Knowing how OAuth issues user IDs clarifies where auth.uid() values come from and their trustworthiness.

Physical Security Access Cards

auth.uid() is like a unique access card ID used to open doors in a building.

This cross-domain link shows how unique IDs control access in both digital and physical worlds.

Common Pitfalls

#1 Allowing access without checking auth.uid() leads to data leaks.

Wrong approach:

CREATE POLICY "Allow all" ON table FOR SELECT USING (true);

Correct approach:

CREATE POLICY "Allow owner" ON table FOR SELECT USING (user_id = auth.uid());

Root cause:

Not restricting access by user ID means anyone can read all data.

#2 Using auth.uid() in insert policies only, forgetting update policies.

Wrong approach:

CREATE POLICY "Insert owner" ON table FOR INSERT WITH CHECK (user_id = auth.uid());

Correct approach:

CREATE POLICY "Update owner" ON table FOR UPDATE USING (user_id = auth.uid());

Root cause:

Missing update policies lets users modify rows they don't own.

#3 Comparing auth.uid() to a non-unique or mutable field like email.

Wrong approach:

USING (email = auth.uid())

Correct approach:

USING (user_id = auth.uid())

Root cause:

Emails can change or be duplicated; uid is stable and unique.

Key Takeaways

auth.uid() is the unique identifier of the logged-in user used in database policies to control access.

Policies using auth.uid() ensure users can only access or modify their own data, protecting privacy and security.

auth.uid() is only available for authenticated requests and is null for anonymous or service role calls, which must be handled carefully.

Combining auth.uid() with other conditions allows flexible and precise access control tailored to real-world needs.

Understanding how auth.uid() works inside the database prevents common security mistakes and helps build robust applications.

Practice

1.

What does auth.uid() represent in Supabase row-level security policies?

easy

A. The current logged-in user's unique ID

B. The database server's ID

C. The table's primary key

D. The user's email address

Solution

1. Step 1: Understand the purpose of auth.uid()

   auth.uid() is a function that returns the unique identifier of the currently logged-in user in Supabase.

2. Step 2: Identify what auth.uid() is not

   It does not return server or table IDs, nor user email addresses directly.

3. Final Answer:

   The current logged-in user's unique ID -> Option A

4. Quick Check:

   auth.uid() = current user ID [OK]

Hint: auth.uid() always means the logged-in user's ID [OK]

Common Mistakes:

• Thinking auth.uid() returns email
• Confusing auth.uid() with table keys
• Assuming auth.uid() is server ID

2.

Which of the following is the correct syntax to allow a user to select only their own rows in a table with a user_id column?

CREATE POLICY "Select own rows" ON my_table FOR SELECT USING ( ... );

easy

A. user_id = current_user()

B. auth.uid() = user_email

C. user_id == auth.uid()

D. user_id = auth.uid()

Solution

1. Step 1: Check correct equality operator in policies

   Supabase policies use single equals = for comparison, not double equals ==.

2. Step 2: Match user_id with auth.uid()

   The correct way is to compare the table's user_id column to auth.uid().

3. Final Answer:

   user_id = auth.uid() -> Option D

4. Quick Check:

   Use single = and compare user_id to auth.uid() [OK]

Hint: Use single = to compare user_id with auth.uid() [OK]

Common Mistakes:

• Using double equals == in policy
• Comparing auth.uid() to email column
• Using current_user() instead of auth.uid()

3.

Given this policy on orders table:

CREATE POLICY "Users can select own orders" ON orders FOR SELECT USING (user_id = auth.uid());

What happens if a user with auth.uid() = 'abc123' runs a query to select orders?

medium

A. They see only orders where user_id is 'abc123'

B. They see all orders regardless of user_id

C. They get a syntax error

D. They see no orders at all

Solution

1. Step 1: Understand the policy condition

   The policy allows selecting rows where user_id equals the current user's ID.

2. Step 2: Apply the policy to the user's query

   The user with ID 'abc123' will only see rows where user_id is 'abc123'.

3. Final Answer:

   They see only orders where user_id is 'abc123' -> Option A

4. Quick Check:

   Policy filters rows by user_id = auth.uid() [OK]

Hint: Policy filters rows to match auth.uid() user_id [OK]

Common Mistakes:

• Thinking user sees all rows
• Expecting syntax error from correct policy
• Assuming no rows are returned

4.

Identify the error in this policy that aims to restrict updates to a user's own rows:

CREATE POLICY "Update own rows" ON profiles FOR UPDATE USING (user_id = auth.uid);

medium

A. user_id should be user_email

B. Wrong operator, should use == instead of =

C. Missing parentheses after auth.uid

D. Policy name cannot have spaces

Solution

1. Step 1: Check the usage of auth.uid()

   auth.uid is a function and must be called with parentheses: auth.uid().

2. Step 2: Verify other parts of the policy

   The operator = is correct, user_id is the right column, and policy names can have spaces.

3. Final Answer:

   Missing parentheses after auth.uid -> Option C

4. Quick Check:

   auth.uid() needs parentheses to call function [OK]

Hint: Always call auth.uid() with parentheses [OK]

Common Mistakes:

• Forgetting () after auth.uid
• Using == instead of = in policies
• Changing user_id to email incorrectly

5.

You want to create a policy that allows users to update their own profile only if their email is verified. The profiles table has columns user_id and email_verified (boolean). Which policy condition correctly enforces this?

hard

A. email_verified = true

B. user_id = auth.uid() AND email_verified = true

C. auth.uid() = user_id AND email_verified = false

D. user_id = auth.uid() OR email_verified = true

Solution

1. Step 1: Combine user ownership and email verification

   The policy must check both that the row belongs to the user and that their email is verified.

2. Step 2: Use AND to require both conditions

   Using AND ensures both user_id = auth.uid() and email_verified = true must be true.

3. Final Answer:

   user_id = auth.uid() AND email_verified = true -> Option B

4. Quick Check:

   Use AND to combine user_id and email_verified checks [OK]

Hint: Use AND to require both user_id and email_verified true [OK]

Common Mistakes:

• Using OR instead of AND
• Checking email_verified = false
• Omitting user_id check