Protected routes in frontend in Supabase - Deep Dive

Overview - Protected routes in frontend

What is it?

Protected routes in frontend are parts of a website or app that only certain users can see. These routes check if a user is logged in or has permission before showing the page. If the user is not allowed, they are sent to a login page or another safe place. This helps keep private information safe and controls who can do what.

Why it matters

Without protected routes, anyone could see or change private parts of a website, like personal profiles or settings. This can lead to data leaks or unauthorized actions. Protected routes make sure only the right people get access, keeping users' data safe and the app trustworthy.

Where it fits

Before learning protected routes, you should understand basic frontend routing and user authentication concepts. After this, you can learn about role-based access control and backend security to build stronger protections.

Mental Model

Core Idea

Protected routes act like locked doors in a building that only open if you have the right key, which is your login or permission.

Think of it like...

Imagine a club with a bouncer at the door checking if you have a membership card. If you do, you enter; if not, you wait outside or go somewhere else.

┌───────────────┐
│ User Requests │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Check Login   │──No──> Redirect to Login Page
│ or Permission │
└──────┬────────┘
       │Yes
       ▼
┌───────────────┐
│ Show Protected│
│ Content       │
└───────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Frontend Routing Basics

Concept: Learn how frontend apps show different pages without reloading the whole site.

Frontend routing means the app changes what you see by switching views inside the browser. For example, clicking a menu link shows a new page but the browser doesn't reload. This is done using tools like React Router or similar libraries.

Result

You can navigate between pages smoothly in a single-page app.

Knowing routing basics is essential because protected routes build on controlling which pages users can see.

2

Foundation

Introduction to User Authentication

Concept: Understand how apps know who you are by logging in.

Authentication means proving your identity, usually by entering a username and password. When you log in, the app remembers you using tokens or cookies. This lets the app know you are allowed to see certain pages.

Result

Users can log in and the app can recognize them on different pages.

Authentication is the key that protected routes check before allowing access.

3

Intermediate

Implementing Basic Protected Routes

🤔Before reading on: do you think protected routes block access by hiding links or by checking on page load? Commit to your answer.

Concept: Learn how to block access to pages by checking if a user is logged in before showing the page.

In Supabase with React, you check if the user is logged in using Supabase's auth methods. If not logged in, you redirect them to the login page. This check happens before rendering the protected page component.

Result

Users who are not logged in cannot see protected pages and are sent to login.

Understanding that protection happens during routing prevents unauthorized users from seeing sensitive content.

4

Intermediate

Using Supabase Session for Route Protection

🤔Before reading on: do you think session data is stored on the server or client side? Commit to your answer.

Concept: Use Supabase's session info stored in the browser to decide if a route is accessible.

Supabase stores session info in local storage or cookies. Your frontend reads this session to know if the user is logged in. You can listen for session changes and update route access dynamically.

Result

Route access updates automatically when user logs in or out.

Knowing how session data flows helps build responsive and secure route protections.

5

Advanced

Handling Role-Based Access in Routes

🤔Before reading on: do you think all logged-in users should see the same protected pages? Commit to your answer.

Concept: Add checks for user roles or permissions to control access beyond just login status.

Supabase allows storing user roles in metadata or database. Your frontend fetches this info and checks if the user has the right role before showing certain pages. For example, only admins can see admin pages.

Result

Different users see different protected pages based on their roles.

Understanding role checks prevents privilege escalation and enforces fine-grained security.

6

Expert

Securing Routes Against Token Expiry and Refresh

🤔Before reading on: do you think a user stays logged in forever after login? Commit to your answer.

Concept: Manage token expiration and refresh to keep route protection reliable over time.

Supabase tokens expire after some time. Your app must detect expired tokens and refresh them or log the user out. If not handled, users might see protected pages without valid sessions or get unexpected logouts.

Result

Users have seamless access while tokens are valid; expired tokens trigger re-authentication.

Knowing token lifecycle prevents security holes and improves user experience.

Under the Hood

Protected routes work by intercepting navigation events in the frontend. When a user tries to visit a route, the app checks the current authentication state stored in memory or local storage. If the user is not authenticated or lacks permission, the app redirects them to a safe page like login. Supabase manages authentication tokens and sessions, which the frontend reads to verify identity and roles. This check happens before rendering the protected content, ensuring unauthorized users never see sensitive data.

Why designed this way?

This design keeps frontend apps fast and responsive by avoiding full page reloads. It also separates concerns: Supabase handles authentication securely on the backend, while the frontend enforces access control dynamically. Alternatives like server-side checks exist but add latency and complexity. The chosen method balances security with user experience, making apps feel smooth while protecting data.

┌───────────────┐
│ User Requests │
└──────┬────────┘
       │
       ▼
┌─────────────────────────┐
│ Frontend Router Intercept│
└──────┬──────────────────┘
       │
       ▼
┌─────────────────────────┐
│ Check Supabase Session  │
│ and Token Validity      │
└──────┬──────────────────┘
       │
   Yes │ No
       ▼    ┌───────────────┐
┌───────────┐│ Redirect to   │
│ Render    ││ Login or      │
│ Protected ││ Refresh Token │
│ Page      │└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do protected routes alone guarantee backend data security? Commit yes or no.

Common Belief: If the frontend blocks access, the backend data is safe from unauthorized users.

Reality: Frontend protection only hides UI elements; backend APIs must also enforce security checks.

Why it matters: Relying only on frontend protection can lead to data leaks if backend APIs accept unauthorized requests.

Quick: Can a user stay logged in forever without re-authentication? Commit yes or no.

Common Belief: Once logged in, users remain authenticated indefinitely without needing to log in again.

Reality: Authentication tokens expire and must be refreshed or users must log in again.

Why it matters: Ignoring token expiry can cause unexpected logouts or security risks if expired tokens are accepted.

Quick: Does hiding links to protected pages prevent all unauthorized access? Commit yes or no.

Common Belief: If a link to a protected page is hidden, users cannot access that page at all.

Reality: Users can still type the URL directly; route checks must block access regardless of link visibility.

Why it matters: Relying on hiding links alone leaves protected pages vulnerable to direct URL access.

Quick: Is role-based access control always handled on the frontend? Commit yes or no.

Common Belief: Frontend alone can securely enforce user roles and permissions.

Reality: Role checks must also be enforced on the backend to prevent spoofing or tampering.

Why it matters: Without backend role enforcement, attackers can bypass frontend checks and access restricted data.

Expert Zone

1

Supabase session listeners can trigger UI updates instantly on login/logout, improving user experience without manual refresh.

2

Token refresh failures should gracefully log out users to avoid stale sessions causing confusing errors.

3

Combining frontend route guards with backend row-level security policies in Supabase creates a strong defense-in-depth security model.

When NOT to use

Protected routes are not enough when backend APIs are public or lack authentication checks. In such cases, use backend authentication and authorization mechanisms like Supabase Row Level Security or API gateways to secure data.

Production Patterns

In real apps, protected routes are combined with global state management to track user sessions. Role-based UI components show or hide features dynamically. Token refresh logic runs in background services or hooks to maintain seamless access. Logging and monitoring detect unauthorized access attempts.

Connections

Backend Authentication and Authorization

Builds-on

Understanding frontend protected routes helps grasp why backend security is essential to fully protect data and actions.

Session Management in Web Applications

Same pattern

Knowing how sessions work explains how protected routes know if a user is logged in or not.

Physical Security Systems

Analogy

Recognizing that protected routes are like security checkpoints helps understand layered security in software.

Common Pitfalls

#1 Allowing access to protected pages without checking authentication on route change.

Wrong approach:

function ProtectedPage() {
return Secret Content;
}

// Route setup without auth check
} />

Correct approach:

function ProtectedPage() {
const session = supabase.auth.getSession();
if (!session) {
return ;
}
return Secret Content;
}

} />

Root cause:

Missing authentication check allows anyone to access protected content.

#2 Not handling token expiration, causing stale sessions and errors.

Wrong approach:

const session = supabase.auth.session();
// No check for token expiry
if (session) {
showProtectedContent();
}

Correct approach:

const session = supabase.auth.getSession();
if (session && !isTokenExpired(session)) {
showProtectedContent();
} else {
redirectToLogin();
}

Root cause:

Ignoring token lifecycle leads to invalid session usage.

#3 Hiding links to protected routes but not blocking direct URL access.

Wrong approach:

function Nav() {
const session = supabase.auth.session();
return {session && Admin};
}
// No route guard on /admin

Correct approach:

function AdminPage() {
const session = supabase.auth.getSession();
if (!session) return ;
return Admin Content;
}

} />

Root cause:

Relying on UI hiding without route checks leaves pages exposed.

Key Takeaways

Protected routes control access to parts of a frontend app by checking user login and permissions before showing pages.

They rely on authentication sessions managed by services like Supabase to know who the user is.

Frontend protection must be combined with backend security to fully protect data and actions.

Handling token expiration and role-based access improves security and user experience.

Common mistakes include missing route checks, ignoring token lifecycle, and relying only on hiding links.

Practice

1. What is the main purpose of protected routes in a frontend application using Supabase?

easy

A. To allow only logged-in users to access certain pages

B. To speed up page loading times

C. To store user data permanently

D. To change the app's theme automatically

Solution

1. Step 1: Understand what protected routes do

   Protected routes restrict access to certain pages so only authorized users can see them.

2. Step 2: Connect with Supabase session usage

   Supabase sessions help check if a user is logged in, enabling route protection.

3. Final Answer:

   To allow only logged-in users to access certain pages -> Option A

4. Quick Check:

   Protected routes = restrict access to logged-in users [OK]

Hint: Protected routes block access unless user is logged in [OK]

Common Mistakes:

• Thinking protected routes speed up loading
• Confusing route protection with data storage
• Assuming protected routes change app appearance

2. Which of the following is the correct way to check if a user is logged in using Supabase in frontend code?

easy

A. const user = supabase.auth.getUser()

B. const user = supabase.session()

C. const user = supabase.auth.session()

D. const user = supabase.auth.getSession()

Solution

1. Step 1: Identify Supabase method for session retrieval

   Supabase's current method to get session info is auth.getSession(), which returns user session data.

2. Step 2: Compare options with official API

   Options A, B, and C are outdated or incorrect method names; only getSession() is valid.

3. Final Answer:

   const user = supabase.auth.getSession() -> Option D

4. Quick Check:

   Use auth.getSession() to check login [OK]

Hint: Use supabase.auth.getSession() to get current user session [OK]

Common Mistakes:

• Using deprecated methods like auth.session()
• Calling supabase.session() which does not exist
• Confusing getUser() with getSession()

3. Given this React snippet using Supabase, what will happen if the user is not logged in?

const session = supabase.auth.getSession();
if (!session) {
  navigate('/login');
} else {
  showDashboard();
}

medium

A. The dashboard is shown regardless

B. An error is thrown because getSession() is async

C. The user is redirected to the login page

D. Nothing happens; the page stays the same

Solution

1. Step 1: Understand getSession() behavior

   supabase.auth.getSession() is an asynchronous function returning a Promise, so calling it without await assigns a Promise object to session, not session data.

2. Step 2: Analyze the code flow

   A Promise object is truthy, so if (!session) evaluates to false, and showDashboard() executes regardless of login status.

3. Final Answer:

   The dashboard is shown regardless -> Option A

4. Quick Check:

   Async getSession() without await returns truthy Promise [OK]

Hint: Remember to await async getSession() calls [OK]

Common Mistakes:

• Treating async getSession() as synchronous
• Assuming session is null if user not logged in
• Ignoring Promise returned by getSession()

4. You wrote this code to protect a route but it redirects even logged-in users to login:

const { data: session } = supabase.auth.getSession();
if (!session) {
  window.location.href = '/login';
}

What is the main issue?

medium

A. session is always truthy even if user is logged out

B. window.location.href cannot redirect pages

C. getSession() is asynchronous and must be awaited

D. You must use supabase.auth.getUser() instead

Solution

1. Step 1: Check getSession() usage

   supabase.auth.getSession() returns a Promise and must be awaited or handled asynchronously to get session data.

2. Step 2: Understand destructuring without await

   Destructuring data from a Promise without await results in undefined or incorrect values, so session is not properly checked.

3. Final Answer:

   getSession() is asynchronous and must be awaited -> Option C

4. Quick Check:

   Always await async getSession() calls [OK]

Hint: Always await async Supabase calls to get real data [OK]

Common Mistakes:

• Not awaiting async functions
• Thinking window.location.href can't redirect
• Using getUser() instead of getSession() incorrectly

5. You want to protect a React page so only logged-in users can see it. Which approach correctly implements this using Supabase's session and React hooks?

function ProtectedPage() {
  const [session, setSession] = React.useState(null);

  React.useEffect(() => {
    const getSession = async () => {
      const { data } = await supabase.auth.getSession();
      setSession(data.session);
      if (!data.session) {
        navigate('/login');
      }
    };
    getSession();
  }, []);

  if (!session) return <p>Loading...</p>;
  return <div>Welcome to protected content!</div>;
}

hard

A. The navigate call should be outside the async function

B. This code correctly protects the page by redirecting unauthenticated users

C. The code should call supabase.auth.getUser() instead of getSession()

D. The session state should be initialized with supabase.auth.getSession() synchronously

Solution

1. Step 1: Analyze async session retrieval in useEffect

   The code correctly uses an async function inside useEffect to get the session and update state.

2. Step 2: Check redirect logic for unauthenticated users

   If no session exists, the code calls navigate('/login') to redirect users, protecting the page.

3. Step 3: Confirm loading state handling

   While session is null, it shows a loading message, preventing content flash before redirect.

4. Final Answer:

   This code correctly protects the page by redirecting unauthenticated users -> Option B

5. Quick Check:

   Async session check + redirect = protected route [OK]

Hint: Use async useEffect with redirect on no session [OK]

Common Mistakes:

• Using getUser() instead of getSession() for session check
• Calling navigate outside async context incorrectly
• Initializing session state synchronously causing errors