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.
30 lines
847 B
JSON
30 lines
847 B
JSON
{
|
|
"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"
|
|
}
|
|
}
|