Client Portal Auth

Status: 💭 Brainstorm

One-liner: Per-site access control with Microsoft/Google login, role-based permissions for client organizations.

---

Problem

Currently all project sites are public. Need to:

1. Gate client sites behind authentication
2. Allow client employees to access only their sites
3. Support Microsoft login (clients use M365)
4. Keep personal sites (pool, kira, etc.) either public or Sean-only

Key Decisions Needed

• Which sites stay public vs gated?
• How granular do permissions get? (site-level? page-level?)
• Self-registration or invite-only?
• How to handle multiple clients? (each gets their own domain prefix: bf., clientb., etc.)

Notes

2026-04-25 — Initial discussion

• oauth2-proxy already running on oc.beyond20.ca (Google login works)
• Microsoft login: use Azure AD multi-tenant app registration
• Filter by email domain: *@buildforce.ca → BF sites only
• Sean (seankibbee@gmail.com) → admin, sees everything
• Cookie domain .oc.beyond20.ca needed for cross-subdomain auth
• Each client's sites already namespaced (bf.*, future clients would get their own)

Architecture sketch

• Single oauth2-proxy instance with multiple providers (Google + Microsoft)
• Permissions config: JSON file mapping email/domain → allowed sites
• nginx auth_request on each gated site
• Public sites skip auth entirely

Prerequisites for AI Site Editor

• This auth system is a prerequisite for the AI Site Editor project
• Editor permissions build on top of view permissions