Retire Cloudflare Access: demo on Google + email codes, cf-access deprecated

Demo: `/auth/sso` and the `ACCESS_*` config are gone. Staff sign in with
Google like everyone else, and `POST /api/staff` promotes a view session at
`STAFF_DOMAIN` to the admin gate, so one registered redirect URI serves both.
Copy no longer offers Access/SSO.

Library: README leads with Google/OIDC + email codes; the Access adapter moves
to a "Legacy" note and its exports are `@deprecated` — kept until gcs and
cw-s3 (pinned to older SHAs, still importing it) finish migrating.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DyJyzSYpRxJuL6x6NyjpG3

Author: ryan-williams

README.md

@@ -104,15 +104,7 @@ if (res.ok) return new Response(null, { headers: { 'set-cookie': res.cookie } })
 
 Every knob is optional; zero-config is an unlimited-use, never-expiring, unnamed link. `maxRedeems` counts **sessions minted** (≈ distinct browsers), not requests — which is what makes "one-use link" mean what a human predicts. Note that `maxRedeems: 1` is hostile UX in practice (the recipient opens it on their phone, then their laptop, and is locked out); prefer unlimited-redeem, named, logged, and revocable.
 
-**SSO.** Point one CF Access application at `/auth/sso` and leave the rest of the site public at the edge:
-
-```ts
-import { ssoHandler } from '@open-athena/auth/cf-access'
-
-export const onRequest = ssoHandler({ gate, teamDomain: 'https://acme.cloudflareaccess.com', aud: env.ACCESS_AUD })
-```
-
-**Or skip Access entirely.** `@open-athena/auth/oidc` signs people in against an OIDC provider directly, so the hosted chooser and its generic copy are replaced by a page you own:
+**Sign in with Google** (or any OIDC issuer). `@open-athena/auth/oidc` signs people in against the provider directly — no Cloudflare Access, no Zero Trust seats, and a sign-in page you own. Pair it with One Tap (`GoogleOneTap`) in the page and email codes (below) for addresses Google can't vouch for:
 
 ```ts
 import { GOOGLE, oidcCallback, oidcStart } from '@open-athena/auth/oidc'
@@ -139,9 +131,7 @@ Authorization-code flow, confidential clients only, nothing persisted between th
 
 A verified address that policy rejects redirects with `?denied=<email>` rather than 403ing, which is what lets an app pre-fill request-access with an address the *provider* vouched for instead of one the visitor typed.
 
-There's also a seat argument: every Access-authenticated user consumes a Cloudflare Zero Trust seat, while share links never touch Access at all. A growing allowlist hits that ceiling; this is the way off it.
-
-`ssoSessionHandler` is the same thing for a deployment that can mint sessions but not verify them — the auth store lives in another worker, so there's no gate to hand it. It takes `{ secret, teamDomain, aud, cookieName }` and mints for any Access-verified email; the gate that later verifies the cookie re-derives scopes from `policy` on every request, so authorization isn't being skipped, just deferred to where it can be answered.
+**Legacy: Cloudflare Access** (`@open-athena/auth/cf-access`). The package began as a layer *on* Access — Access authenticated, the gate added share links and the log — and the adapter still exists for deployments that haven't cut over: `ssoHandler` trades an Access JWT on one Access-gated path (`/auth/sso`) for a gate session, and `ssoSessionHandler` does the same where the verifying gate lives in another worker. It's deprecated in favour of the OIDC + email-code path above, which does the same job without Access: every Access-authenticated user consumes a Zero Trust seat (the free tier caps at 50), and the hosted chooser can't be styled. It will be removed once its last consumers have migrated.
 
 **Revocation is instant.** Grant-backed sessions re-join their grant row on every request, so `gate.revoke(id)` kills every session that link ever minted — no waiting out a cookie TTL. That property is what makes the social story work: assume links get forwarded, and design so forwarding is *visible and revocable* rather than prevented.
 
@@ -257,8 +247,8 @@ The default read is the Cloud Identity API, which is what honours a group-*owner
 
 ```tsx
 <AuthGate
-  source={{ kind: 'app' }}          // or { kind: 'edge' } for Tier 1 — the only line that changes
-  signIn={<SignInPanel signInUrl="/auth/sso" requestAccess />}
+  source={{ kind: 'app' }}
+  signIn={<SignInPanel googleUrl="/auth/google" emailAuth requestAccess />}
 >
   {whoami => <>
     <AccessNotice whoami={whoami} />   {/* "Private link for Bob Smith · access is logged" */}

demo/README.md

@@ -6,7 +6,7 @@ Three pages:
 
 | Path | What it shows |
 |---|---|
-| `/` | The ways in: the library's `SignInPanel` (Google One Tap + redirect, Access SSO, an emailed code), and — more prominently — two share links you can just click |
+| `/` | The ways in: the library's `SignInPanel` (Google One Tap + redirect, an emailed code / magic link), and — more prominently — two share links you can just click |
 | `/dashboard` | The gated page. The wall in front of it, then a page whose only content is what the gate knows about you |
 | `/admin` | The power-user side, in a throwaway sandbox: mint links, watch their log, disable / rotate / revoke them, edit an allowlist and run a (simulated) directory sync |
 
@@ -27,15 +27,15 @@ Step 5 is the load-bearing one: grant-backed sessions re-join their grant row on
 **Simulated, and labelled as such in the page:**
 
 - **Mail.** `emailCodeAuth`'s `start` reply never says whether mail went out (so the form can't probe who's allowed), and delivery *is* the verification. This demo has no sending domain for most visitors, so its `send` captures the message instead of mailing it, stashes it in a short-lived `HttpOnly` cookie only your browser can read back (`GET /auth/email/outbox`), and the form shows you the code and link. That proves nothing about the address, and the page says so. Mail really goes out only when `RESEND_API_KEY` + `MAIL_FROM` are set *and* the recipient's domain is in `MAIL_DOMAINS` — a public form that mails whatever address a stranger types is a spam cannon pointed at other people.
-- **Google.** Without `GOOGLE_CLIENT_ID` / `GOOGLE_CLIENT_SECRET`, `/auth/google/*` answers 503, so the page drops One Tap and the Google button (and says why) rather than offering a sign-in that can't complete. The staff SSO button is likewise hidden under `pnpm dev`, where no Cloudflare Access sits in front of `/auth/sso`. Google exposes no API to create the client; `scripts/provision-oauth-client.mjs` walks the one manual step.
+- **Google.** Without `GOOGLE_CLIENT_ID` / `GOOGLE_CLIENT_SECRET`, `/auth/google/*` answers 503, so the page drops One Tap and the Google button (and says why) rather than offering a sign-in that can't complete. Google exposes no API to create the client; `scripts/provision-oauth-client.mjs` walks the one manual step.
 - **The directory sync.** `Admin → Allowlist → Sync now` `replaceSource`s `sync:staff@example.org` with a random subset of a five-person roster, returning the same `[{ group, source, count }]` shape `syncGroupsToAllowlist` returns. A real deployment puts that call at the marked spot in `functions/api/admin/[[path]].ts`, with a service-account key. The table isn't wired into any policy here (the demo admits any address) — which demonstrates a real property: mounting the editor never changes who gets in; `allowlistPolicy(store)` in the gate's `policy` is the separate line that does.
 
 ## Two gates, one grants table
 
 `functions/_lib/gates.ts` builds two gates over the same D1 store:
 
-- **`viewGate`** (`oa_demo_view`) — guards the dashboard. Its policy admits staff and *anyone who isn't a sandbox identity*: an email session (SSO, Google, or an emailed code — they all end in `gate.signIn`) re-derives its scopes from this policy on every request, so "who may sign in by email" is decided in that one line. A real deployment writes `domainPolicy`, `allowlistPolicy`, or both there.
-- **`adminGate`** (`oa_demo_admin`) — guards the admin page. Staff get `admin` + `requests` + `reports`; a sandbox identity gets `admin` only, so a visitor playing admin still meets the wall on the dashboard and has to mint themselves a link.
+- **`viewGate`** (`oa_demo_view`) — guards the dashboard. Its policy admits staff and *anyone who isn't a sandbox identity*: an email session (Google or an emailed code — both end in `gate.signIn`) re-derives its scopes from this policy on every request, so "who may sign in by email" is decided in that one line. A real deployment writes `domainPolicy`, `allowlistPolicy`, or both there.
+- **`adminGate`** (`oa_demo_admin`) — guards the admin page. Staff (Google sign-ins at `STAFF_DOMAIN`, promoted from their view session by `POST /api/staff` — one registered redirect URI serves both gates) get `admin` + `requests` + `reports`; a sandbox identity gets `admin` only, so a visitor playing admin still meets the wall on the dashboard and has to mint themselves a link.
 
 Separate cookie names let one browser hold both roles at once. The shared store is what makes revocation in one visible to the other.
 
@@ -63,18 +63,17 @@ Migrations come straight from the package (`migrations_dir = "../migrations"`),
 wrangler d1 create oa-auth-demo          # paste database_id into wrangler.toml
 wrangler d1 migrations apply oa-auth-demo --remote
 wrangler pages secret put SESSION_SECRET # openssl rand -base64 32
-wrangler pages secret put ACCESS_AUD     # the Access application's AUD tag
 pnpm deploy
 ```
 
-Then, for SSO, create **one** Cloudflare Access application covering `auth.oa.dev/auth/sso` and nothing else. Narrowness is the point: the landing page and its og:image stay publicly crawlable so unfurls work, and Access is reduced to an IdP on a single path. Set `ACCESS_TEAM_DOMAIN` in `wrangler.toml` to your Zero Trust team domain.
+No Cloudflare Access / Zero Trust anywhere: the whole site is public at the edge, and the gate is the app's.
 
 Optional, each turning a simulated thing real (see `wrangler.toml` for the full list):
 
 - `RESEND_API_KEY` + `MAIL_FROM` (`scripts/provision-resend.mjs` stores both) and `MAIL_DOMAINS` — email codes are mailed to those domains.
 - `GOOGLE_CLIENT_ID` + `GOOGLE_CLIENT_SECRET` (`scripts/provision-oauth-client.mjs`) — Google sign-in and One Tap work.
 
-Without any of them, `/auth/sso` returns 401, `/auth/google/*` returns 503, and codes show on screen — everything else (share links, request-access, the log, the allowlist) still works.
+Without any of them, `/auth/google/*` returns 503, and codes show on screen — everything else (share links, request-access, the log, the allowlist) still works.
 
 ## Caveats
 

demo/functions/_lib/gates.ts

@@ -1,8 +1,8 @@
 /**
  * Two gates over one grants table.
  *
- * `viewGate` guards the dashboard — the thing a share link, an emailed code, a
- * Google sign-in or SSO gets you into. `adminGate` guards the admin page where
+ * `viewGate` guards the dashboard — the thing a share link, an emailed code or a
+ * Google sign-in gets you into. `adminGate` guards the admin page where
  * links are minted, watched and revoked. They use different cookie names, so a
  * visitor can hold an admin session and a recipient session at once, and the
  * same D1 store, so revoking in the admin page kills the dashboard session on
@@ -40,8 +40,7 @@ export interface Env {
   /** Google OAuth "Web application" client. Absent = `/auth/google/*` answers 503 and the buttons are inert. */
   GOOGLE_CLIENT_ID?: string
   GOOGLE_CLIENT_SECRET?: string
-  ACCESS_TEAM_DOMAIN?: string
-  ACCESS_AUD?: string
+  /** Google sign-ins at this domain may promote to the admin gate (`/api/staff`). */
   STAFF_DOMAIN?: string
 }
 
@@ -113,7 +112,7 @@ export function gates(env: Env, req: Request) {
     profiles,
     secret,
     cookieName: VIEW_COOKIE,
-    // An email session (SSO, Google, or an emailed code — they all end in
+    // An email session (Google or an emailed code — both end in
     // `gate.signIn`) re-derives its scopes from this policy on every request,
     // so "who may sign in by email" is decided here and nowhere else.
     policy: firstMatch(domainPolicy([staffDomain], [VIEW_SCOPE]), anyoneButSandbox([VIEW_SCOPE])),

demo/functions/api/staff.ts

@@ -0,0 +1,24 @@
+/**
+ * Promote a staff Google sign-in to the admin gate.
+ *
+ * Google sign-in lands in `viewGate` (one registered redirect URI serves both
+ * gates). The admin page then POSTs here: if the view session is an email
+ * session the *admin* gate's policy admits — the staff domain — this mints the
+ * admin cookie for the same address. Anyone else gets a 403, and a sandbox
+ * never reaches this (it has no view session).
+ */
+import { type Env, gates, json } from '../_lib/gates.js'
+
+interface Ctx {
+  request: Request
+  env: Env
+}
+
+export const onRequestPost = async ({ request, env }: Ctx): Promise<Response> => {
+  const { viewGate, adminGate } = gates(env, request)
+  const auth = await viewGate.authenticate(request, undefined, { logView: false })
+  if (!auth || auth.kind !== 'sso') return json({ error: 'sign in first' }, 401)
+  const signedIn = await adminGate.signIn(auth.email, request)
+  if (!signedIn) return json({ error: 'not staff' }, 403)
+  return json({ ok: true, email: auth.email }, 200, { 'set-cookie': signedIn.cookie })
+}

demo/functions/auth/email/[[path]].ts

@@ -9,7 +9,7 @@
  *   GET  /auth/email/outbox  -> demo only, see below
  *
  * They sign into the same gate the dashboard checks, so an emailed code, a
- * Google sign-in and Cloudflare Access all converge on one `gate.signIn`.
+ * and Google sign-in converge on one `gate.signIn`.
  *
  * **The dishonest step.** The library's `start` never says whether mail went
  * out — the reply is identical for an admitted and a not-admitted address, so

demo/functions/auth/google/[[path]].ts

@@ -8,7 +8,8 @@
  *   POST /auth/google/onetap        -> `googleOneTapVerify`: same verification, session in this response
  *   GET  /auth/google/client        -> demo only: the public client id, so the page knows whether to render One Tap
  *
- * Both land in `viewGate.signIn`, like an emailed code or Access SSO. Dormant
+ * Both land in `viewGate.signIn`, like an emailed code; staff then promote to
+ * the admin gate via `/api/staff`. Dormant
  * (503) until a client exists: Google exposes no API to create one, so
  * `scripts/provision-oauth-client.mjs` walks the one manual step and stores
  * `GOOGLE_CLIENT_ID` / `GOOGLE_CLIENT_SECRET` as Pages secrets.

demo/functions/auth/sso.ts

@@ -3,15 +3,15 @@
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <title>@open-athena/auth — share links, SSO, and an access log</title>
+    <title>@open-athena/auth — share links, Google sign-in, and an access log</title>
     <meta
       name="description"
       content="Live demo: sign in with Google or an emailed code, or open a share link; mint your own, watch what the recipient did, revoke it and see the session die."
     />
     <meta property="og:title" content="@open-athena/auth" />
     <meta
       property="og:description"
-      content="Named share links, SSO, email codes, and an access log for gated dashboards. Try it: open a link, mint your own, watch the log, revoke it."
+      content="Named share links, Google sign-in, email codes, and an access log for gated dashboards. Try it: open a link, mint your own, watch the log, revoke it."
     />
     <meta property="og:image" content="https://auth.oa.dev/og.jpg" />
     <meta name="twitter:card" content="summary_large_image" />

demo/index.html

@@ -8,7 +8,7 @@ const FORM = { form: 'stack', field: 'field', input: 'input', button: 'btn', mes
 /**
  * The composed sign-in every gated page here shows — the library's own
  * `SignInPanel`, wired the way an adopter would wire it: Google (in-page One
- * Tap, then the redirect button), Cloudflare Access for staff, and an emailed
+ * Tap, then the redirect button) and an emailed
  * code for everyone else. All three end in the same `gate.signIn`, so the
  * dashboard can't tell them apart, which is the point.
  */
@@ -43,9 +43,6 @@ export function SignIn({ onSignedIn, title }: { onSignedIn: () => void; title?:
       <SignInPanel
         title={title}
         googleUrl={clientId ? '/auth/google/start?next=%2Fdashboard' : undefined}
-        // Cloudflare Access fronts `/auth/sso` only on the deployed host; in local dev it can only 401.
-        signInUrl={import.meta.env.DEV ? undefined : '/auth/sso?next=%2Fdashboard'}
-        signInLabel="Sign in with SSO (staff)"
         withNext={false}
         emailAuth={{
           startEndpoint: '/auth/email/start',

demo/src/SignIn.tsx

@@ -1,15 +1,25 @@
 import { type Grant, subjectName } from '@open-athena/auth'
 import { AllowlistPanel, type AppWhoami, Avatar, useWhoami } from '@open-athena/auth/react'
 import { useMutation, useQuery, useQueryClient } from '@tanstack/react-query'
-import { type FormEvent, useState } from 'react'
+import { type FormEvent, useEffect, useState } from 'react'
 import { ago, api, startSandbox } from '../api.js'
 
 const SOURCE = { kind: 'app', endpoint: '/api/admin/whoami' } as const
 const SANDBOX_KEY = 'oa-auth-demo:sandbox'
 
 export function Admin() {
   const { whoami, refresh } = useWhoami<AppWhoami>(SOURCE)
-  if (whoami === undefined) return <p className="muted">Checking…</p>
+  // A staff member who signed in with Google holds a *view* session; promote it
+  // to the admin gate once (`/api/staff` 403s anyone outside the staff domain).
+  const [promoted, setPromoted] = useState<boolean | null>(null)
+  useEffect(() => {
+    if (whoami !== null || promoted !== null) return
+    void fetch('/api/staff', { method: 'POST', credentials: 'include' }).then(res => {
+      setPromoted(res.ok)
+      if (res.ok) refresh()
+    })
+  }, [whoami, promoted, refresh])
+  if (whoami === undefined || (whoami === null && promoted === null)) return <p className="muted">Checking…</p>
   if (whoami === null) return <StartSandbox onStarted={refresh} />
   return <Console whoami={whoami} />
 }
@@ -43,8 +53,8 @@ function StartSandbox({ onStarted }: { onStarted: () => void }) {
         {busy ? 'Starting…' : 'Start a sandbox'}
       </button>
       <p className="muted small">
-        Staff can instead <a href="/auth/sso?next=%2Fadmin">sign in with SSO</a>, which also unlocks the access-request
-        queue.
+        Staff (<code>@openathena.ai</code>) can instead <a href="/auth/google/start?next=%2Fadmin">sign in with Google</a>,
+        which also unlocks the access-request queue.
       </p>
     </div>
   )