# How to Set Up Authenticated Routes in Bubble

- Tool: Bubble
- Difficulty: Beginner
- Time required: 15-20 min
- Compatibility: All Bubble plans
- Last updated: March 2026

## TL;DR

Protecting pages in Bubble requires checking if the user is logged in on every page load and redirecting unauthenticated visitors to a login page. This tutorial covers adding Page is loaded workflows that check login status, redirecting to login with return URL preservation, implementing role-based page access for different user types, and handling deep links that require authentication before accessing specific content.

## Overview: Authenticated Routes in Bubble

This tutorial shows you how to protect pages in your Bubble app so only logged-in users (or users with specific roles) can access them. You will implement login redirects with return URL handling.

## Before you start

- A Bubble app with user authentication set up
- A login page built and functional
- Basic understanding of Workflows and page events
- A User Data Type with role field (for role-based access)

## Step-by-step guide

### 1. Add a login check to protected pages

On every page that requires authentication, go to the Workflow tab and create a new event: Page is loaded. Add a condition: Only when Current User is logged out. Add the action: Navigation → Go to page → your login page. This redirects anyone who is not logged in to the login page immediately on page load. Add this workflow to every protected page in your app. For efficiency, you can add this check to a reusable header element that appears on all protected pages.

**Expected result:** Unauthenticated users are automatically redirected to the login page when accessing protected pages.

### 2. Preserve the intended destination URL through login

When redirecting to login, pass the original page URL as a parameter so users return to their intended page after logging in. Modify the redirect workflow: Go to page → login, and check 'Send more parameters to the page'. Add a parameter 'redirect' with value being the current page URL. On the login page, after a successful login workflow, check if the redirect parameter exists using Get data from page URL → redirect. If it exists, use Go to page with that URL. If not, go to the default dashboard page.

> Pro tip: URL-encode the redirect parameter value to handle pages with their own parameters. Use :encoded as URL format.

**Expected result:** Users are returned to the page they originally tried to access after successfully logging in.

### 3. Implement role-based page access

Add a 'role' field to your User Data Type (text or Option Set with values like 'admin', 'manager', 'user'). On admin-only pages, add a Page is loaded workflow with two conditions: redirect if Current User is logged out (to login), and also redirect if Current User's role is not 'admin' (to an unauthorized page or dashboard). Create a simple 'Access Denied' page that explains the user does not have permission and provides a link back to the dashboard. For more complex role hierarchies, use a number-based level system where admin = 3, manager = 2, user = 1, and check if the role level is sufficient.

**Expected result:** Pages enforce both authentication and role-based access, redirecting unauthorized users appropriately.

### 4. Handle deep links requiring authentication

Deep links are direct URLs to specific content, like a shared order page (yourapp.com/order?id=12345). When an unauthenticated user clicks such a link, they should be redirected to login and then returned to the exact same URL including parameters. Extend your redirect logic to capture the full URL including query parameters. On the login page redirect, reconstruct the full destination URL with all original parameters. Test by opening a protected deep link in an incognito window, logging in, and verifying you arrive at the intended content.

**Expected result:** Deep links work correctly through the authentication flow, returning users to the exact intended page with parameters.

### 5. Protect sensitive elements within pages

Some pages may be accessible to all logged-in users but contain sections only certain roles should see. Add conditional visibility to sensitive elements: set 'This element is visible when' to Current User's role is 'admin'. Also check 'Collapse when hidden' so the layout adjusts. For data protection, add Privacy Rules on the underlying Data Types so even if someone inspects the page source, the data is not accessible. Remember that hiding an element does not protect its data — Privacy Rules are the true security layer.

**Expected result:** Sensitive page sections are visible only to authorized roles, with data protected by Privacy Rules.

## Complete code example

File: `Workflow summary`

```text
AUTHENTICATED ROUTES SUMMARY
=====================================

BASIC AUTH CHECK:
  Event: Page is loaded
  Only when: Current User is logged out
  Action: Go to page → Login
    Send parameter: redirect = current page URL

LOGIN REDIRECT:
  After successful login:
    If redirect parameter exists:
      Go to page → redirect URL
    Else:
      Go to page → Dashboard

ROLE-BASED ACCESS:
  User Data Type: role (admin/manager/user)
  Admin pages:
    Page is loaded + logged out → Login
    Page is loaded + role ≠ admin → Access Denied
  Manager pages:
    Page is loaded + role not in [admin, manager]
      → Access Denied

DEEP LINK HANDLING:
  Capture full URL including parameters
  Pass as redirect parameter to Login
  After login, reconstruct full URL
  Navigate to original destination

ELEMENT-LEVEL PROTECTION:
  Conditional visibility: role = required role
  Collapse when hidden: checked
  Privacy Rules: server-side data protection

SECURITY LAYERS:
  Layer 1: Page-level redirect (UX)
  Layer 2: Element visibility (UI)
  Layer 3: Privacy Rules (data)
```

## Common mistakes

- **Only hiding elements without setting Privacy Rules** — Hidden elements' data is still accessible in the page source and network requests. Privacy Rules are the only true data protection. Fix: Always set Privacy Rules on sensitive Data Types in addition to conditional element visibility
- **Not adding auth checks to every protected page** — Missing the check on even one page creates a security hole where users can access content directly via URL Fix: Add the Page is loaded auth check to every protected page, or use a reusable element approach
- **Losing URL parameters during the login redirect** — When redirecting to login and back, query parameters from the original URL are lost, breaking deep links Fix: Capture the full URL including parameters and pass it through the login flow as an encoded redirect parameter

## Best practices

- Add authentication checks to every protected page without exception
- Preserve the original URL through the login flow for seamless deep linking
- Use Privacy Rules as the primary security mechanism, not just UI hiding
- Create role-based access using a role field on the User Data Type
- Build an Access Denied page for clear unauthorized access messaging
- Test all protected pages in incognito mode to verify redirects work
- Log access attempts for security auditing

## Frequently asked questions

### Does Bubble have built-in route protection?

No. Bubble does not have automatic route protection. You must add Page is loaded workflows with login checks to every protected page manually.

### Can users bypass page-level redirects?

The redirect happens on page load, so a brief flash of content may appear. For truly sensitive data, Privacy Rules prevent data from being sent to unauthorized users regardless of page access.

### How do I protect API endpoints?

For backend workflows exposed as API endpoints, check the 'This workflow requires authentication' option or validate an API token in the workflow logic.

### Can I protect all pages with a single configuration?

Not natively. The most efficient approach is adding the auth check to a reusable header element used on all protected pages.

### What about single sign-on (SSO)?

SSO can be implemented using OAuth2 via the API Connector for enterprise authentication providers like Okta or Auth0. The route protection logic remains the same.

### Can RapidDev help set up authentication and access control?

Yes. RapidDev can implement comprehensive authentication systems including role-based access, SSO integration, and security audits for Bubble applications.

---

Source: https://www.rapidevelopers.com/bubble-tutorial/setup-authenticated-routes-in-bubble
© RapidDev — https://www.rapidevelopers.com/bubble-tutorial/setup-authenticated-routes-in-bubble