Remove dev-login: Cognito is the only authentication provider

[satvikOS]

⛔ DO NOT MERGE until Cognito is populated

Cognito holds 1 confirmed identity. The approved roster is 82 people. Merging this today removes the only way 81 of them can sign in. This PR is correct and complete; the condition that gates it is not in this repository.

The exact precondition for merging: every person on the approved Tenant #1 roster has a CONFIRMED identity in Cognito user pool us-east-1_EBxatAx2Z and can sign in with it. Confirmed, not created — an account left in FORCE_CHANGE_PASSWORD exists and still cannot authenticate, because src/lib/auth/cognito.ts refuses a Cognito challenge rather than half-handling it. The ops-status workflow reports both numbers; apps/web/scripts/provision-cognito-cohort.mjs does the provisioning and is a dry run by default.

Opened as a draft for that reason. PD-005 already set this order and it has not changed: provision → verify → remove.

One step that is not in the diff and must not be skipped. After merging and deploying, rotate AUTH_SECRET (Actions → Rotate Auth Secret). Removing the provider stops new dev-login sessions; it does not invalidate ones already issued. Sessions are JWTs validated by signature alone, so anyone holding a cookie minted while dev-login was on stays signed in as whoever they typed, for the life of that token, after the door is closed behind them. Then delete the now-unmanaged tenure-pilot/dev-login secret from Secrets Manager.

---

What this removes

Provider	the dev-login Credentials provider in src/lib/auth.ts
Gate	src/lib/dev-login.ts + dev-login.test.ts
Env	AUTH_DEV_LOGIN, ALLOW_DEV_LOGIN_IN_PRODUCTION, DEV_LOGIN_PASSPHRASE — out of the schema, the task definition and the deploy workflow
Infra	infrastructure/terraform/dev-login-gate.tf (generated passphrase, Secrets Manager secret, two outputs), the ARN in secrets.tf, the secret ref in ecs.tf
UI	the second form on /signin, the "Pilot access" divider, and every conditional that arranged two providers

The three Cognito variables are now the whole of authentication.

The contract flipped direction

env.ts used to warn on a half-configured pool, because a missing Cognito field meant one provider was absent from a page that still had another. With one provider that same state is a site nobody can log into, so it is fatal at boot — and the message names which of the three variables is unset, rather than restating the rule.

The e2e suite kept its coverage

All 34 Playwright specs authenticated through the dev-login form. Cognito verifies credentials with an IAM-authorized AdminInitiateAuth call against a real user pool, which CI has no credentials for and a fork PR never will.

The suite now establishes the session directly (e2e/support/auth.ts): next-auth/jwt's own encode, the server's AUTH_SECRET, the salt and cookie name @auth/core derives for the deployment's URL, and the user id read out of the seeded database. That is the cookie the server issues, decrypted by the same code; the jwt and session callbacks run and every authorization decision downstream — tenant scope, the (app) entitlement gate, capability resolution — is taken for real against real rows.

ADR-0019 records the decision, the three options rejected (a real pool in CI; an endpoint override in production code; a second provider for tests), and the one property it costs: redirectTo: callbackUrl in the sign-in action is no longer executed end to end, and is asserted structurally instead. The destination behaviour is still exercised in a browser from the other side of the same code — /signin holding a session redirects to the same validated callbackUrl, so the off-origin case still has to land on /dashboard.

e2e/signin-cognito.spec.ts replaces dev-login-gate.spec.ts: the form is there, it is the only form, a credential the pool refuses becomes page state rather than a 500 or a blank page, a refusal leaves no session, and an authenticated person reaches the app with the server agreeing who they are. In CI the pool is real code talking to real AWS and being refused — the log shows Cognito sign-in unavailable: UnrecognizedClientException, mapped to the same generic refusal a wrong password would get.

Governance

Record	Was	Now
IDENT-001-dev-login-in-production	BLOCKED_ARCHITECTURE	PASS, liveViolation: null, evidence re-pointed, review date kept
ADR-0008	Proposed (2026-08-17). Records a conflict; decides nothing.	Accepted — one word, no qualifier — option C, with what it does not decide split out
ADR-0019	—	added, Accepted
ADR-0006	prerequisite 1 named AUTH_DEV_LOGIN=false	dated amendment: that state will never exist; the substance is unchanged
PD-005 / PD-006	sequencing only	+ where the removal stands, and a correction: the @tenure.demo rows do not go with the provider
README index, HANDOFF, RUNBOOK, SESSION-STATE, PROGRAM-BACKLOG	stale	re-pinned

The register row was designed to trip, and it did. Its liveViolation asserted AUTH_DEV_LOGIN=true was still present in the task definition, so fixing the conflict turns the suite red and forces somebody to close the row. That worked exactly as intended — and it is one-shot. A closed row has no predicate left, so the standing guard is now a test: lib/auth/cognito-is-the-only-provider.test.ts fails if a second provider, any of the three retired switches, or the Secrets Manager entry returns — in the application, in the task definition, in Terraform, or in .env.example.

liveViolation is null rather than inverted to expect: "absent". The field's documented meaning is "a condition that holds because the conflict is unresolved"; there is no such condition here any more, and writing absent would keep the row red-on-fix while claiming the opposite of what the field means.

Deliberately still open. §19.1 asks for MFA, recovery and session controls alongside invitation-only authentication and verified email ownership. The pool enforces the first two; MFA is not enabled. IDENT-001 therefore keeps its 2026-09-30 review date instead of being cleared, and ADR-0008 says so under "What this ADR does not decide" rather than qualifying its status.

Verification

tsc --noEmit 0 · jest 106 suites, 1574 passed · next build 0 · Playwright 163/163 against a real Postgres, a production build and the CI environment.

Negative controls — each broken, confirmed RED, restored, confirmed GREEN:

Control	Result
Re-add a dev-login Credentials provider to auth.ts	RED — 2 suites
Put AUTH_DEV_LOGIN back in ecs.tf (app code untouched)	RED
Read process.env.AUTH_DEV_LOGIN in a component, bypassing the schema	RED
ADR-0008 back to Proposed while the register says PASS	RED — 3 assertions
Register claims PASS with state: "proposed"	RED — including the dedicated guard
Accepted (code done; cohort provisioning outstanding)	RED — the one-word rule
Runner given a secret the server does not know	RED — "there is still a working way in" fails, so the minted session is genuinely validated rather than waved through

The last one is the control that matters: it is the difference between a fixture that proves the app admits an authenticated person and one that proves nothing.

A defect the suite caught and I had missed: e2e/app.spec.ts located the sign-in form by getByRole("region", { name: "Pilot access" }) and contained no string my greps matched. Fixed, and it is why the full suite was run rather than the auth specs alone.

Out of scope, flagged not fixed

Resolved, not deferred. The four surviving "Office of Student Experience" strings this section used to list are gone: #119 landed the Engagement rename on main, and the merge below takes main's string in e2e/app.spec.ts. Nothing is outstanding here.

Left to its owner: OKTA_ISSUER / OKTA_CLIENT_ID / OKTA_CLIENT_SECRET are still in apps/web/.env.example. PD-004 retired Okta and src/lib/env.ts has no OKTA_* in its schema, so nothing reads them — but PR #123 is already removing the last Okta mentions from that exact file, and deleting them here would collide with it for no gain. They now carry a comment saying they are dead and why they are still there.

A defect on main, not in this PR: apps/web/prisma/migrations/20260820180000_seat_metering_events/migration.sql:14 and apps/web/src/lib/billing/seat-meter-boundary.test.ts:131 both cite ADR-0015 for the seat-metering boundary. That decision landed as ADR-0018; 0015 is reserved for the platform exception object. Two stale citations, already merged, and not this branch's to rewrite.

---

Adversarial verification (second agent, independent worktree)

Every number in "Verification" above was reproduced from a clean checkout of 7caa9e5
(npm ci, own Postgres, own production build):

Gate	Claimed	Reproduced
tsc --noEmit	0	0
jest	106 suites / 1574	106 suites / 1574 passed, 1 skipped
next build	0	0
Playwright	163/163	163/163 (59.5s, real Postgres + next start)

All seven claimed negative controls were re-run independently and each went RED for the
stated reason, then GREEN on restore — including the decisive one: runner given a secret the server does not
know → "there is still a working way in" fails (waitForURL(/\/dashboard/) times out, not a
connection error). The constant-time claim on secretsMatch was measured, not read: ~1700 ns
across exact-match, same-length-differs-at-byte-0, same-length-differs-at-byte-63 and 1-char
candidates — indistinguishable. Sign-in is non-enumerable in observable output: an address in
the database and one absent from it both produce one identical message, one identical URL.

Three escapes were found in the guards this PR relies on, and are now closed (c061937)

The register row is one-shot, so cognito-is-the-only-provider.test.ts is the standing guard.
It was escapable. Each escape was demonstrated before being fixed:

1. A working passwordless provider was invisible to both guards. Both files found providers
   with /Credentials\(\{\s*\n\s*id:\s*"..."/, which only matches when id is the first
   key. Writing name: before id: — a one-line reordering — hid a second dev-login provider
   that signed in any seeded address with no password. tsc 0, all 106 suites and 1574
   tests green, with that backdoor installed.
2. "Every Credentials provider gates before returning a user" could not fail for an appended
   provider. It split the file on Credentials({, so the last block ran to end-of-file and
   absorbed the callbacks section; signIn there mentions gateOnEligibility, so the final
   provider always read as gated. An appended provider with no eligibility check passed.
   Appending is how a provider arrives.
3. The retired-switch scan missed process.env["AUTH_DEV_LOGIN"]. It matched only the dotted
   form. The bracket form is the same read and the same schema bypass the test's own comment says
   it covers.

Fixed by bounding each provider at its own closing brace in one shared parser
(src/lib/auth/provider-blocks.ts), reading id wherever it sits among the keys, asserting a
textual count of Credentials( against the parsed count so an unreadable declaration fails
closed, and matching the bracket form. All three escapes now go RED, plus a fourth control
(Credentials(someVariable)) which the new count assertion catches. Gate re-run after the fix:
tsc 0 · jest 106 suites / 1575 passed · next build 0 · Playwright 163/163.

Confirmed by test, not by reading: sessions are replayable across sign-out

The AUTH_SECRET rotation step above is load-bearing, not hygiene. Measured: a session cookie
captured before sign-out, replayed in a fresh browser context after that user signed out,
returns 200 from /api/auth/session as director@tenure.demo and loads /dashboard. Sign-out
clears the cookie in one browser; it does not end the session. So rotating AUTH_SECRET after
deploy is the only thing that invalidates sessions minted while dev-login was live. (PR #104,
"Sessions the server can actually end", is the durable fix and is not merged.)

Scope and asset checks

• The PR is a draft — as instructed. ✅
• The branding agent did not remove dev-login on its branch; it preserved the provider. ✅
• No second authorization path. The changes to eligibility.ts, csp.ts, [tenant]/page.tsx
  and slack/install.ts are comment/docstring-only; secretsMatch's body is byte-identical. ✅
• No fabricated or trademarked asset. Zero image/font files added, zero data: URIs, zero
  base64 payloads in the diff; the only Simon reference in an added line is a test fixture
  address. ✅
• Zero-mock rule holds. Two matches for stub markers across the whole diff, both benign: a
  test counting the existing "Coming soon" SSO notice, and a comment in env.ts about rejecting
  placeholders. ✅
• One honest caveat on the e2e suite, which the spec file itself already states: because the CI
  pool is unreachable, "an address with no account behind it is refused the same way" passes via
  the unavailable branch rather than by exercising Cognito's user-existence collapsing. The
  non-enumerability is structural — refuseToSignIn always redirects to ?error=1 and the page
  renders exactly one message string — so the property holds, but that spec is not what proves it.

🤖 Generated with Claude Code

---

Independent review (third agent, own worktree, own database)

The gate was reproduced from scratch at c061937 — own npm ci, own Postgres, own production build, own port, because port 3000 was another agent's server and reuseExistingServer would have run the suite against their build without saying so.

Gate	Claimed	Reproduced at c061937
tsc --noEmit	0	0
jest	106 suites / 1574	106 suites / 1575 passed, 1 skipped
next build	0	0
Playwright	163/163	163/163 (59.7s, real Postgres + next start)

The decisive control re-run independently: runner given a secret the server does not know → "there is still a working way in" fails on waitForURL(/\/dashboard/) timing out, not a connection error. The session fixture is genuinely validated by the server.

Answering the review's own question — was e2e coverage migrated or deleted? Migrated. main had 34 specs, all 34 importing support/auth.ts, whose submitSignIn hard-asserted getByRole("region", { name: "Pilot access" }). The branch has 33 (dev-login-gate.spec.ts retired, signin-cognito.spec.ts added), all 33 still importing it, now via establishSession. No spec was silently dropped: the one other list difference, seat-metering.spec.ts, is a file main gained after the branch point.

The branch could not merge, and fixing that surfaced four defects

mergeable was CONFLICTING. main had moved on and #119 rebuilt /signin into two zones — while deliberately keeping dev-login as a de-emphasised "Pilot access" panel, because removing it was this PR's job. The resolution is main's layout with that panel taken out. Everything below was found by doing that merge and running the suite, not by reading the diff.

1. The unit divider test asserted a divider EXISTS. expect(divider).toBeGreaterThan(-1) — Name the unit Engagement, and give the sign-in page a hierarchy #119's card draws no "Or" at all, so the test failed on a page that is correct because it has none. It now asserts the invariant (every separator is guarded by something governing its neighbour), which a page with no separators satisfies, plus a separate row recording that today there are none.
2. The e2e divider check had the same artefact. dividers === ssoNotices → dividers <= ssoNotices. Caught by running the suite.
3. ADR-0015 collided. main's index reserves 0015 by name for the platform exception object (One exception object and one operator worklist — and the ADR-0013 fork answered on a new table #101) and 0016 for another change in the same sequence — and five open PRs each wrote themselves an ADR-0015. decision-records.test.ts fails a reserved number that has a file (verified: 4 assertions RED). This change's ADR is now ADR-0019; all 13 references moved with it.
4. .env.example was missed entirely. RUNBOOK calls it the file that "documents every variable for local setup", and it still assigned all three retired switches and named no COGNITO_* variable — so following the documentation produced an app with no provider at all and a sign-in page with no form. Neither standing guard could see it: one walks src for TypeScript, the other walks *.tf. Both now also read .env.example, for the dead switches and for the live ones.

Also fixed: RUNBOOK's "while it is still on" procedure told an operator to set DEV_LOGIN_PASSPHRASE as a repository secret or let Terraform generate one into tenure-pilot/dev-login — both mechanisms are deleted by this PR, so read after the merge it was a procedure that appears to work and does nothing.

Gate on the merged tree

tsc 0 · jest 122 suites / 1873 passed, 1 skipped · next build 0 · Playwright 168/168.

Negative controls — each broken, confirmed RED, restored, confirmed GREEN:

Control	Result
AUTH_DEV_LOGIN=true back in .env.example	RED — the new guard
COGNITO_USER_POOL_ID removed from .env.example	RED — the other half
An "Or" divider gated on the tenant alone	RED — 2 assertions
The ADR put back at the reserved 0015	RED — 4 assertions, incl. "a reserved number has no ADR file"
A second Credentials provider, name: before id:, no gate	RED — 3 assertions

Confirmed, and unchanged by the merge

• It stays a draft. ✅ Cognito still holds 1 identity against ~82 people; the precondition in the first paragraph is the merge gate and is unchanged.
• AUTH_SECRET rotation is in the plan and was not erased with the thing it warns about: RUNBOOK keeps it as step 3 of 4, the rotate-auth-secret.yml workflow is real (openssl rand, put-secret-value, ecs update-service), and the first paragraph of this body repeats it.
• The removal is complete. No dev-login / devLogin / AUTH_DEV_LOGIN reference survives in src, e2e, infrastructure or .github except deliberate history comments and the negative tests that assert the switches no longer do anything. No terraform plan hard error: nothing references dev-login-gate.tf's resources.
• Governance. PD-005 Accepted with the sequencing intact · ADR-0008 Accepted, one word, no qualifier · IDENT-001 PASS with liveViolation: null and a written rationale for not inverting it — the backwards predicate was tripped on purpose and closed, and the standing guard is now a test. 38 governance assertions pass.
• The sign-in page is coherent with one provider — verified in a browser at 1440px and 390px: one form, zero dividers, one SSO notice, zero passphrase fields, and "Office of Student Engagement".

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 1fe66323-0f74-4337-bbfd-2d9cb0ca05bc

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[satvikOS]

ADR number arbitration — this PR must renumber to ADR-0019

Five open PRs each independently claim ADR-0015. main is at ADR-0014, so every parallel agent picked "the next free number":

PR	claims	assigned
#101 the platform exception object	0015	0015
#107 the billable unit	0015	0016
#107 seat metering without an outbox	0016	0017
#110 workspaces are a function of role	0015	0018
#112 e2e authentication without a second provider	0015	0019
#106 tenant configuration packs	0015	0020

Why numbers cannot simply be assigned per-PR

decision-records.test.ts asserts expect(gaps).toEqual([5]) — the reserved Cognito-cutover number is the only permitted gap. So the numbering must be contiguous, which means it follows merge order, not PR order.

Merge order is therefore fixed: #101 → #107 → #110 → #112 → #106. Merging out of that order makes the next PR's CI red on the gap check — which is the guard working, not a flake.

What this PR needs to change

ADR-0015-e2e-authentication-without-a-second-provider.md → ADR-0019-e2e-authentication-without-a-second-provider.md

Rename the file and update every cross-reference: the ADR body, the docs/decisions/README.md table, the backlog, code comments, and any test that pins an ADR number. decision-records.test.ts fails if the README table and the files disagree; constitution-completeness-compiler.test.ts checks supersession shape.

Do not create a new gap, and do not touch 0005.

(Assigned from the collision audit.)

[satvikOS]

ADR allocation — CORRECTED. This PR takes ADR-0020

My earlier table missed #104, which also adds an ADR-0015. Six open PRs claim that number: #101, #104, #106, #107, #110, #112.

decision-records.test.ts asserts expect(gaps).toEqual([5]) — the reserved Cognito number is the only permitted gap. So numbering must be contiguous as merged, which makes merge order and number order the same thing.

merge order	PR	number
1	#101 the platform exception object	0015
2	#104 session revocation event emission	0016
3	#107 the billable unit / seat metering	0017 + 0018
4	#110 workspaces are a function of role	0019
5	#112 e2e authentication without a second provider	0020
6	#106 tenant configuration packs	0021

#116 is out of this sequence entirely — it takes no number at all, deferring to ADR-0009, which already exists, is already Proposed, and already owns the same fork (which of RestrictedIdentity / DirectoryPerson / User is canonical), tracked by register row IDENT-002. One record beats two restating one conflict. #115 only edits ADR-0013 and is unconstrained.

#104 is placed second, not last, because it is verified and ready while #106 is blocked on two real defects — a ready PR must not queue behind a stuck one.

Verified the hard way: renaming an ADR to 0021 on a branch whose numbers stop at 0014 yields gaps [5,15,16,17,18,19,20] and CI goes red. Measured, not predicted.

Rename the file and update every cross-reference — the ADR body, the docs/decisions/README.md table, the backlog, code comments, and any test pinning a number. A code comment contradicting the ADR it cites is the one a reader finds first.

[satvikOS]

Closing. #140 does this properly, and #112 carries two defects that make it unsafe to land as-is.

#112's intent is right and is not being dropped — /signin becomes Cognito-only, the pilot block and passphrase go, and the credentials provider is deleted. #140 does all of that AND rebuilds the page, so keeping both open means two branches removing the same provider.

Two measured reasons this specific branch should not be the one that lands:

1. It would make a failed deploy unrecoverable. Deleting infrastructure/terraform/dev-login-gate.tf takes aws_secretsmanager_secret.dev_login with it, and that resource carries recovery_window_in_days = 0 — which the AWS provider turns into ForceDeleteWithoutRecovery. The ECS rollback revision still references that secret, so a deploy failing after the delete could not roll back.

2. Resolving its ecs.tf in its favour silently deletes MASTER_ACCESS_EMAILS from the production task definition. The rollout preview then goes dark with no test failing — resolvePreviewIdentity returns null for an unset value by design, so /preview 404s and the role chooser goes inert. It reads as "never deployed" rather than as a merge error.

Also carried forward to #140: this branch adds ADR-0019-e2e-authentication-without-a-second-provider.md while main already has ADR-0019-workspaces-are-a-function-of-role.md. Two different filenames on the same number produce no gap, and the ADR checks are gap-based — so it merges green and the log permanently carries two ADR-0019s. It needs renumbering, and the repo should gain the uniqueness assertion it believed it had.

One requirement from here that is currently prose and must become a step: sessions are JWT and signature-only, so cookies minted while dev-login was live stay valid after the provider is gone. AUTH_SECRET has to be rotated at the deploy that removes it — nothing enforces that today.