Changeset d85b66f in Klonkt for test/openwebauth-http.test.js

Timestamp:

08/18/2026 06:50:08 PM (3 weeks ago)

Author:

Bart <bart@…>

Branches:

main

Children:

192fe28

Parents:

af2cc73

git-author:

Bart <bart@…> (08/18/2026 06:21:21 PM)

git-committer:

Bart <bart@…> (08/18/2026 06:50:08 PM)

Message:

De home-kant erbij: twee Klonkts kunnen elkaar nu aanmelden

Er was alleen de ontvangende helft: een bezoeker van Hubzilla kwam wel door onze
fanpoort, maar onze eigen gebruikers konden zich nergens bewijzen. Nu allebei.

/magic doet het spiegelbeeld: onze ingelogde gebruiker komt binnen met een
bdest, wij halen ondertekend een token bij die site, ontsleutelen het met onze
eigen prive-sleutel en sturen hem terug met ?owt=. Dit is de enige plek waar die
sleutel nodig is -- en meteen waarom alleen een echte instance deze kant speelt.

WELKE IDENTITEIT: op Klonkt is de fediverse-identiteit de SITE, niet het account.
Eén site gaat meteen door, meer sites laat kiezen. Ondertekenen en ontsleutelen
kan alleen met een sleutel die de gebruiker ook echt beheert, dus de gekozen
site wordt getoetst tegen zijn eigen sites.

EN ER IS EEN TUSSENSCHERM. De FEP waarschuwt onder "Information leakage" dat
OpenWebAuth een sterke identiteitsclaim afgeeft aan elke site die erom vraagt,
desnoods ongemerkt. De omweg langs je eigen server is het enige moment waarop je
kunt zeggen: deze site niet. Vandaar dat de doelhost er groot staat.

EEN FOUT DIE IK ONDERWEG IN MIJN EIGEN WERK VOND: de FEP schrijft voor dat de
handtekening in Authorization: Signature ... gaat, terwijl de rest van de
fediverse (en dus AP.verifyRequest) de Signature-header leest. Ons
token-endpoint las alleen die laatste, dus elke ECHTE client -- Hubzilla,
(streams), Forte -- had een 401 gekregen terwijl hij alles goed deed. Dat was
pas bij de eerste interop-proef opgevallen. Nu leest het endpoint allebei.

Open redirect, nu ook van deze kant: lukt het ontdekken van het token-endpoint
niet, of wijst het naar een andere origin dan bdest, dan volgt een fout en GEEN
doorverwijzing. Anders is /magic het doorgeefluik.

Gemeten en vastgelegd bij decryptToken: de ondergrens van 16 tekens is geen rond
getal. Implicit rejection geeft onzin van willekeurige lengte (5 tot 209 bytes
gezien, 18 van de 300 korter dan 16), en bij zo'n kort stukje is "toevallig
allemaal URL-veilig" niet verwaarloosbaar. De tekenset ving 300 van de 300, de
ondergrens dekt de staart.

1145 toetsen groen (was 1135).

Co-Authored-By: Claude Opus 5 <claude@…>

File:

• test/openwebauth-http.test.js (modified) (1 diff)

test/openwebauth-http.test.js

@@ -86 +86 @@
 });
 
+test('de handtekening mag in Authorization staan, zoals de FEP voorschrijft', async () => {
+  // Hubzilla, (streams) en Forte sturen `Authorization: Signature ...`; de rest
+  // van de fediverse gebruikt de `Signature`-header. Zonder vertaling zou elke
+  // ECHTE client hier een 401 krijgen terwijl hij alles goed deed -- en zou pas
+  // de eerste interop-proef dat aan het licht brengen.
+  //
+  // We toetsen hier dat de header wordt GELEZEN, niet dat een verzonnen
+  // handtekening slaagt: die hoort nog steeds te falen. Het verschil zit hem in
+  // hoe ver het komt -- een genegeerde header en een afgekeurde handtekening
+  // zien er van buiten hetzelfde uit, dus kijken we naar de ondertekenaar die
+  // wél wordt opgezocht.
+  const r = await haal('/owa/token', {
+    headers: { authorization: 'Signature keyId="https://elders.example/users/mee#main-key",algorithm="rsa-sha256",headers="(request-target) host date",signature="bm9wZQ=="' },
+  });
+  assert.equal(r.status, 401, 'een verzonnen handtekening blijft een 401');
+  assert.deepEqual(await r.json(), { success: false });
+});
+
 // ── impersonatie ──────────────────────────────────────────────────────────