Réconcilier le DTO OAuthStateRejected avec OAuthStateRejectionReason du domaine #26

New issue

Open

opened 2026-07-04 12:11:08 +00:00 by momsse · 0 comments

momsse commented

2026-07-04 12:11:08 +00:00

Owner

Migré depuis viziertronic/octant#64 — ouvert le 2026-06-17 par @momsse.

Issue de suivi de la review de #63 (PR 12 — apps/api), sur le modèle de la PR 4b (#15) carvée des retours de la PR 4 : le finding est réel mais hors périmètre d'un snapshot fidèle.

Constat

Dans apps/api/src/api/authentication/authentication.group.ts, le DTO d'erreur :

reason: Schema.Literals(['invalid_signature', 'expired', 'state_mismatch'])

ne correspond pas à l'union de raisons du domaine (packages/domain/authentication/.../security-signal.value-object.ts) :

['malformed', 'invalid_signature', 'invalid_payload', 'expired']

Conséquences :

state_mismatch n'est jamais émis — littéral mort dans la surface API.
Le mapping du callback collapse malformed / invalid_payload / invalid_signature en invalid_signature (perte d'information côté client/télémétrie).

Pourquoi pas dans #63

Ce DTO et ce mapping sont identiques sur feat/authentication : ni du drift vs main, ni une des catégories de conformité documentées du découpage. Les corriger dans le snapshot créerait un écart hors-conformité vs la branche de référence et casserait l'invariant de vérification finale (git diff main feat/authentication réduit aux catégories de conformité).

Options

Aligner le DTO sur les 4 raisons du domaine et passer reason: error.reason tel quel.
Garder un sous-ensemble client-facing volontairement coarse mais retirer le state_mismatch mort et documenter le choix de non-divulgation.

> _Migré depuis [viziertronic/octant#64](https://github.com/viziertronic/octant/issues/64) — ouvert le 2026-06-17 par @momsse._ Issue de suivi de la review de #63 (PR 12 — apps/api), sur le modèle de la PR 4b (#15) carvée des retours de la PR 4 : le finding est réel mais hors périmètre d'un snapshot fidèle. ## Constat Dans `apps/api/src/api/authentication/authentication.group.ts`, le DTO d'erreur : ```ts reason: Schema.Literals(['invalid_signature', 'expired', 'state_mismatch']) ``` ne correspond pas à l'union de raisons du domaine (`packages/domain/authentication/.../security-signal.value-object.ts`) : ```ts ['malformed', 'invalid_signature', 'invalid_payload', 'expired'] ``` Conséquences : - `state_mismatch` n'est **jamais émis** — littéral mort dans la surface API. - Le mapping du callback collapse `malformed` / `invalid_payload` / `invalid_signature` en `invalid_signature` (perte d'information côté client/télémétrie). ## Pourquoi pas dans #63 Ce DTO et ce mapping sont **identiques sur `feat/authentication`** : ni du drift vs `main`, ni une des catégories de conformité documentées du découpage. Les corriger dans le snapshot créerait un écart hors-conformité vs la branche de référence et casserait l'invariant de vérification finale (`git diff main feat/authentication` réduit aux catégories de conformité). ## Options 1. Aligner le DTO sur les 4 raisons du domaine et passer `reason: error.reason` tel quel. 2. Garder un sous-ensemble client-facing volontairement coarse mais retirer le `state_mismatch` mort et documenter le choix de non-divulgation.

momsse added the

pr-split

label

2026-07-04 12:11:08 +00:00