Sign in with S256 PKCE over plain HTTP too #112

Merged

jcoffey-dev merged 1 commits from fix/pkce-s256-always into main

2026-10-18 21:54:08 +00:00

jcoffey-dev commented

2026-10-18 21:41:04 +00:00

Owner

On a page served over plain HTTP (a console on a LAN address, say),
browsers leave out crypto.subtle, and sign-in fell back to the plain
PKCE method: the code verifier itself went out as the challenge, so
anyone who saw the authorization request could redeem the code. The
server advertises only S256 but still accepts plain from registered
clients.

src/lib/sha256.ts: our own SHA-256 (FIPS 180-4), used only when
crypto.subtle is missing.
generateCodeChallenge always returns S256.

Tests: digests checked against Python's hashlib (empty, "abc", the
448-bit vector, non-ASCII, and 55/56/64/1000 bytes across block
boundaries) and against crypto.subtle on random input; the old
"falls back to plain" test now checks the same S256 challenge comes
out with and without crypto.subtle. Typecheck, lint, i18n:check,
all 668 tests, build and notice check pass locally. No new strings.

The server will refuse plain in a follow-up inbuxa-server PR; deploy
this console first so a console on plain HTTP keeps signing in.

On a page served over plain HTTP (a console on a LAN address, say), browsers leave out `crypto.subtle`, and sign-in fell back to the `plain` PKCE method: the code verifier itself went out as the challenge, so anyone who saw the authorization request could redeem the code. The server advertises only S256 but still accepts `plain` from registered clients. - `src/lib/sha256.ts`: our own SHA-256 (FIPS 180-4), used only when `crypto.subtle` is missing. - `generateCodeChallenge` always returns S256. Tests: digests checked against Python's hashlib (empty, "abc", the 448-bit vector, non-ASCII, and 55/56/64/1000 bytes across block boundaries) and against `crypto.subtle` on random input; the old "falls back to plain" test now checks the same S256 challenge comes out with and without `crypto.subtle`. Typecheck, lint, i18n:check, all 668 tests, build and notice check pass locally. No new strings. The server will refuse `plain` in a follow-up inbuxa-server PR; deploy this console first so a console on plain HTTP keeps signing in.

jcoffey-dev added 1 commit 2026-10-18 21:41:04 +00:00

ci / build (pull_request) Skipped

Details

ci / publish (pull_request) Skipped

Details

ci / notices (pull_request) Successful in 53s

Details

github/ci (branch) GitHub Actions

Details

ci / github (pull_request) Successful in 1m45s

Details

c390cec026

Browsers leave out crypto.subtle on pages served over plain HTTP, and
sign-in then fell back to the plain PKCE method, sending the verifier
itself as the challenge. The challenge now comes from our own SHA-256
in that case, so it is always S256. The server advertises only S256,
and will refuse plain.

jcoffey-dev merged commit 6526511cef into main

2026-10-18 21:54:08 +00:00

jcoffey-dev deleted branch fix/pkce-s256-always

2026-10-18 21:54:08 +00:00

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: inbuxa/inbuxa-admin#112