Two different questions

Authentication answers who are you? Authorisation answers what may you do? They are often blurred, and the blur causes real flaws: a platform that lets anyone who is signed in open any page has authentication and no authorisation. OWASP's guidance treats them as separate controls for this reason ^{[1] [2]}.

In your platform, Supabase Auth handles authentication: it checks the password or link, and issues a session ^[3]. Everything in this element's chapter 2 is authorisation: the route guard and server checks that apply the matrix, on top of the row-level security from Session 7.

What a session is

After a person signs in, the platform must remember them without asking for the password on every tap. Supabase does this with a pair of tokens: a short-lived access token, a signed statement of who the person is (by default it expires after one hour), and a longer-lived refresh token used to get a new access token quietly while the person keeps working ^[4]. In a Next.js app the tokens are kept in cookies, so the server can read them on every request ^[5].

Short tokens limit the damage if one is copied: it stops working within the hour. When the access admin disables a person, their next refresh fails, and the session ends.

Choosing sign-in for each role

Supabase Auth offers several sign-in methods; pick per role, free options first ^{[3] [7]}:

NIST's digital identity guidelines favour long passwords checked against lists of known breached passwords, no forced periodic changes, and a second factor for anything sensitive ^[8]. In this course: two-step sign-in is required for every role that can approve, change access or see the whole site, and the access admin role cannot sign in without it.

Shared tablets on the line

Operators often share one tablet per line. The temptation is a shared login such as line2. Never do it: every record must say which person made it, and the matrix's scope and separation-of-duties rules depend on knowing who that is. Instead, each operator signs in personally, quickly, and is signed out at the end of the shift.

• Make sign-in fast: large fields at 16 px, a remembered email per device where your policy allows, and a clear error in plain words.
• Sign out on idle and at shift change, so the next person cannot act as the last.
• Keep the session on the tablet only as long as the shift; a lost tablet should hold nothing that works tomorrow.

Open by default is how platforms leak

A common pattern is to check sign-in only on the pages someone remembered to protect. Every new page is open until someone remembers. With AI agents adding pages quickly, that is a leak waiting to happen. OWASP's authorization guidance says the opposite: deny by default, and allow only what is explicitly permitted ^[1].

In this platform the rule is simple: only the routes listed as public are open to everyone (the home page and sign-in). Every other route is closed unless the matrix's screens section opens it to the person's role. A new page that nobody added to the matrix is refused, for everyone, until it is.

Generated, not written

The route table and the decision are generated from access/matrix.json, the same file that generated the database rules in Session 7. Here is what the generator writes:

// lib/access/routes.ts — generated from access/matrix.json. Do not edit by hand.
export const PUBLIC = ["/", "/sign-in", "/auth/callback"];

export const SCREENS: Record<string, string[]> = {
  "/operator":  ["operator"],
  "/review":    ["supervisor"],
  "/dashboard": ["supervisor", "manager"],
  "/work":      ["supervisor", "maintenance"],
  "/people":    ["access_admin"],
};

export type Verdict = "allow" | "sign-in" | "forbidden";

export function decide(path: string, roles: string[] | null): Verdict {
  if (PUBLIC.includes(path)) return "allow";
  if (!roles) return "sign-in";                                   // no valid session
  const screen = Object.keys(SCREENS).find((s) => path === s || path.startsWith(s + "/"));
  if (!screen) return "forbidden";                                // not in the matrix: closed
  return SCREENS[screen].some((r) => roles.includes(r)) ? "allow" : "forbidden";
}

Wiring it into Next.js

Next.js runs a file called proxy.ts (named middleware.ts before Next.js 16) before any page or route, which makes it the natural place for the route guard ^[2]. It reads the Supabase session from the cookies, takes the person's roles from the session token, and asks decide(). Supabase's guide for Next.js shows how to read and refresh the session there ^[3]. A Supabase custom access token hook can copy each person's roles from their assignments into the token at every refresh, so the guard needs no database call; Next.js recommends exactly that for checks in the proxy, which runs on every request ^{[6] [5]}.

// proxy.ts — the route guard. Runs before every page and route.
import { NextResponse, type NextRequest } from "next/server";
import { decide } from "@/lib/access/routes";
import { currentRoles } from "@/lib/access/session"; // roles from the session token; null if none or expired

export async function proxy(request: NextRequest) {
  const roles = await currentRoles(request);
  const verdict = decide(request.nextUrl.pathname, roles);
  if (verdict === "allow") return NextResponse.next();
  if (verdict === "sign-in") return NextResponse.redirect(new URL("/sign-in", request.url));
  return new NextResponse("Not allowed", { status: 403 });
}

// Run on everything except the framework's own static files.
export const config = { matcher: ["/((?!_next/static|_next/image|favicon.ico).*)"] };

Why one lock is not enough

In March 2025 a flaw in Next.js (CVE-2025-29927) let a crafted request header skip middleware entirely in some versions, so any platform whose only check was in middleware was open ^[4]. It was fixed quickly, but the lesson stands: the route guard is the first lock, not the only one. Next.js's own authentication guide recommends checking authorisation again close to the data ^[5].

1. Route guard (proxy.ts): closed unless the matrix opens the route.
2. Server check: every server action and API route calls one generated helper, for example requireRole("supervisor"), which checks the person's current assignment in the database before anything is read or written.
3. Row-level security (Session 7): even a request that slips past both gets only the rows its person's scope allows.

Four tests that prove default deny

Generate the first two kinds from the matrix, like the database tests in Session 7: for every screen, one role that must get in and one that must not. The expired-session test proves that an old cookie found on a shared tablet is worthless. OWASP's session management guidance lists expiry and invalidation as core controls ^[1].

// test/routes.test.mjs — generated cases plus the edge cases.
import assert from "node:assert/strict";
import { decide, SCREENS, PUBLIC } from "../lib/access/routes.ts";

for (const route of PUBLIC) assert.equal(decide(route, null), "allow", `${route} is public`);
for (const [route, roles] of Object.entries(SCREENS)) {
  assert.equal(decide(route, null), "sign-in", `${route}: signed out goes to sign-in`);
  for (const role of roles) assert.equal(decide(route, [role]), "allow", `${route}: ${role} allowed`);
  assert.equal(decide(route, ["nobody"]), "forbidden", `${route}: unknown role refused`);
}
assert.equal(decide("/reports", ["manager"]), "forbidden", "a route not in the matrix is closed");
console.log("route guard: default deny holds");

These test the decision. Add a few end-to-end tests that send real requests to the running app (signed out, as an operator, with an expired cookie) so the wiring in proxy.ts and the server checks is proven too.

Every route accounted for

Session 6's completeness test covered tables. Its twin covers routes: list every page and API route in the app folder and fail if any is neither public nor in the matrix. A new page added without a matrix entry fails CI on the same pull request, before anyone can open it.

Sign-in day to day

Once real people use the platform, sign-in is mostly routine. Write the routines down in the runbook (Session 18) so they happen the same way every time.

• Leavers: the access admin removes the person's assignments and disables their login the same day. Their next token refresh fails, and the server check refuses them at once because it reads current assignments.
• Lost or stolen tablet: sign that device's sessions out from the access admin screen, and require sign-in again.
• Forgotten password: "Forgot your password?" on the sign-in page, so people help themselves; the access admin is the fallback.
• Lockouts and guessing: Supabase Auth limits repeated sign-in attempts ^[2]; your sign-in page should say plainly when to try again and who to ask.
• Quarterly review: each area owner reviews the generated access sheet from Session 6 against who actually works there.