fix(auth): reject SQL LIKE metacharacters in ForwardAuth email claim

[awais786]

Summary

Closes a SQL LIKE wildcard match in the ForwardAuth (AUTH_TYPE=SSO) branch of validateAuthentication by switching the user-lookup from Op.iLike to exact match.

Root cause

The lookup used User.findOne({ where: { email: { [Op.iLike]: email } } }). ILIKE treats % and _ in the supplied value as wildcards, so x-auth-request-email: %@%.% produces ILIKE '%@%.%' which matches every row. The first matched user (typically the bootstrap admin) is then issued a 3-month JWT cookie.

Fix

   user = await User.scope("withTeam").findOne({
-    where: {
-      email: { [Op.iLike]: email },
-    },
+    where: { email },
   });

Exact match strips all special meaning from % and _ — they become ordinary characters and where: { email: "%@%.%" } finds nobody. Email is already .toLowerCase().trim()'d before the lookup, matching the existing User.findByEmail pattern; emails are stored canonically lowercased so case-insensitive matching isn't required.

Reachability in production

Verified the bug is not exploitable from the public internet against docs.foss.arbisoft.com:

• POST /api/auth.info with x-auth-request-email: %@%.% and no session returns HTTP/2 302 redirecting to Cognito. oauth2-proxy intercepts unauthenticated requests before they reach Outline, and overwrites x-auth-request-* headers from the verified OIDC identity for authenticated requests.

This is a defense-in-depth fix at the code level. If the backend is ever directly reachable (k8s NetworkPolicy change, dev environment, internal pivot) or oauth2-proxy is replaced, the code is no longer the failure point.

Test plan

• yarn test server/middlewares/authentication.test.ts — new regression test asserts wildcard input does not impersonate an existing user; all existing ForwardAuth tests still pass (Cognito numeric IDs, real emails, bare-username + DEFAULT_EMAIL_DOMAIN coercion).
• Manual smoke: log in via oauth2-proxy with a Cognito user → still works.

Notes / out of scope

• Wildcard input still falls through to user-provisioning (creates a junk user row). That path is unreachable in prod through oauth2-proxy and is harmless without admin privileges; can be tightened in a follow-up if internal reachability becomes a concern.
• ForwardAuth-minted access-token cookie still has a 3-month TTL outliving IdP-side revocation — separate follow-up.