authentik-qr-login: cross-device QR sign-in for authentik

Scan a QR on your authentik login page with your phone, approve it with a
passkey and a fingerprint, and the laptop signs itself in.

The service holds NO authentik credential. A flow policy calls it with a
session id and gets back the username that approved it, or nothing -- so there
is no standing credential to steal. The obvious alternative, authentik's
recovery-link API, effectively requires a superuser and was rejected for that
reason.

See README.md for the traps this had to work around, including the two
flow-binding settings that are counter-intuitive and load-bearing, and an
honest account of what QR sign-in cannot defend against.

package.json

@@ -0,0 +1,29 @@
+{
+  "name": "authentik-qr-login",
+  "version": "1.0.0",
+  "private": true,
+  "description": "Cross-device QR sign-in for authentik: scan on your phone, approve with a passkey, and the laptop signs itself in. Holds no authentik credential.",
+  "main": "dist/index.js",
+  "scripts": {
+    "build": "tsc",
+    "typecheck": "tsc --noEmit && tsc --noEmit -p tsconfig.test.json",
+    "test": "node --test --experimental-strip-types test/*.test.ts",
+    "start": "node dist/index.js"
+  },
+  "engines": {
+    "node": "22.x"
+  },
+  "dependencies": {
+    "cookie-session": "^2.1.0",
+    "express": "^5.1.0",
+    "openid-client": "^5.6.5",
+    "qrcode": "^1.5.4"
+  },
+  "devDependencies": {
+    "@types/cookie-session": "^2.0.49",
+    "@types/express": "^5.0.6",
+    "@types/node": "^22.10.0",
+    "@types/qrcode": "^1.5.5",
+    "typescript": "^5.9.3"
+  }
+}