Authentication Architecture for Multi-App Ecosystems with Supabase

Building authentication for one app is straightforward. Building it for six interconnected platforms where users need seamless cross-app identity is an entirely different challenge. Here is how Blossend implements authentication across our ecosystem using Supabase Auth as the single source of truth.

The Multi-App Challenge

Blossend operates OpenMyPro (healthcare marketplace), Noizz.io (brand discovery), Blossend.com (ecosystem hub), and three internal tools. A healthcare provider who lists on OpenMyPro should be able to list their brand on Noizz.io without creating a new account. A patient who books on OpenMyPro should see their booking history on Blossend.com. This requires a shared identity system.

Traditional approaches — Auth0, Cognito, Firebase Auth — would require a separate authentication service that all apps connect to. Supabase Auth gives us this natively because all our apps share the same Supabase project. One user table, one session system, one JWT format across every platform.

Supabase Auth Configuration

Our Supabase Auth setup supports three sign-in methods: email/password for users who prefer traditional accounts, Google OAuth for frictionless one-click sign-in, and magic link for password-averse users. Google OAuth handles 72% of our sign-ups because it eliminates the friction of choosing a password.

Each sign-in method returns the same JWT structure. The token contains the user's ID, email, role (patient, provider, admin), and custom metadata including their profile completion percentage and subscription status. This means the downstream application does not care how the user signed in — it only reads the standardized JWT claims.

JWT Token Architecture

Supabase JWTs are signed with our project's secret key and verified by PostgreSQL's RLS engine. The token includes standard claims (sub, iat, exp) plus custom claims we set through Supabase's user metadata. Our custom claims include user_role for permission checks, provider_id for provider-specific queries, and subscription_tier for feature gating.

Token expiration is set to 1 hour with automatic refresh using Supabase's built-in refresh token rotation. The client-side Supabase library handles refresh transparently — the user never sees a sign-in prompt unless they have been inactive for 7 days (our refresh token expiration).

Next.js Middleware for Route Protection

Every protected route in our Next.js apps goes through middleware that verifies the Supabase session. The middleware reads the session cookie, verifies it with Supabase, and either allows the request or redirects to the sign-in page. This happens at the edge, before any page rendering, so protected pages never flash unauthenticated content.

We use a middleware matcher to selectively protect routes. Public pages like the homepage, blog, and provider search skip middleware entirely. Protected pages like the dashboard, booking management, and account settings require a valid session. Admin pages require both a valid session and an admin role claim.

Role-Based Access Control

Our RBAC system has four roles: patient (default), provider, admin, and super_admin. Roles are stored in the user's JWT metadata and enforced at three levels. Middleware checks roles for route-level access. Server Components check roles for UI-level visibility. RLS policies check roles for data-level access.

Provider accounts are created through a separate onboarding flow that verifies professional credentials before granting the provider role. This prevents patients from accessing provider-only features like appointment management, revenue analytics, and patient messaging.

Session Management Across Apps

Cross-app sessions work because all Blossend apps share the same Supabase project and use the same auth cookie domain. When a user signs in on OpenMyPro.com, the session cookie is set for the *.blossend.com domain (our apps use blossend.com subdomains internally). When they navigate to Noizz.io, the shared session automatically authenticates them.

For our public domains (openmypro.com, noizz.io), we implement a lightweight session bridge. A signed redirect token passes the user's session between domains without exposing the full JWT. The receiving app verifies the token with Supabase and establishes a local session. From the user's perspective, they clicked a link and were automatically signed in.

Security Hardening

Beyond the basic auth flow, we implement several security hardening measures. Rate limiting on auth endpoints prevents brute force attacks. Cloudflare Turnstile on sign-up forms prevents bot account creation. PKCE flow for OAuth prevents code interception attacks. And our audit log records every authentication event — sign-in, sign-out, password change, role change — for compliance and forensics.