Skip to main content

Authentication

Every Cubby app gets built-in authentication via Cubby SSO. You don’t need to implement any auth logic.

How It Works

When users access your app:
  1. Request arrives at https://myapp.username.cubby.pro
  2. Envoy Gateway intercepts and checks for valid session cookie
  3. If not logged in: User is redirected to auth.cubby.pro
  4. User authenticates: Magic link or password
  5. Redirect back: User returns to your app with session
  6. Headers injected: User info available in your code

Request Headers

Authenticated requests include these headers:
These headers are set by Cubby’s infrastructure. They’re stripped from incoming requests and re-added after authentication. You cannot spoof them.

Accessing User Info

In API Routes

In Server Components

In Server Actions

User-Scoped Data

Most apps need to scope data by user. Use the userId from headers:

Owner vs Shared Access

Apps can be shared with other users. Both owners and shared users are authenticated, but they have different permissions: Your app code receives the same headers for both. If you need to distinguish:

What NOT To Do

Since Cubby handles authentication, you should NOT:
  • Install auth libraries (NextAuth, Clerk, Auth0, etc.)
  • Create user/session tables in your database
  • Implement login/logout pages
  • Handle password reset flows
  • Store passwords or tokens
All of this is handled by Cubby SSO.

Login Methods

Users can authenticate via:
  • Magic link: Email with one-time login link
  • Password: Traditional email + password
Users manage their login methods at auth.cubby.pro.

Session Duration

  • Inactivity timeout: 7 days without activity
  • Absolute timeout: 90 days maximum
Users are automatically logged out after either timeout.