test(ap1): demonstrate token storage tradeoff

docs/ap1-token-storage.md

@@ -0,0 +1,29 @@
+# AP1 token storage trade-off
+
+AP1에서는 `access_token`, `refresh_token`, `id_token`을
+`oidc-client-ts`의 명시적인 `InMemoryWebStorage`에만 보관한다.
+`localStorage`와 `sessionStorage`에는 OAuth token을 저장하지 않는다.
+
+full-page authorization redirect를 생존해야 하는 일회성 transaction
+state와 PKCE verifier만 `sessionStorage`를 사용한다. callback 성공 후
+라이브러리가 해당 transaction state를 제거한다.
+
+| 저장 위치 | reload 생존 | JavaScript 접근 | AP1 선택 |
+|---|---:|---:|---:|
+| 메모리 | 아니요 | 실행 중 가능 | 사용 |
+| `sessionStorage` | 같은 탭에서 가능 | 가능 | token 저장 금지 |
+| `localStorage` | 예 | 가능 | token 저장 금지 |
+| HttpOnly cookie | 가능 | raw token 접근 불가 | AP2/AP3의 서버 소유 경계 |
+
+메모리 저장은 XSS를 제거하지 않는다. 악성 스크립트가 실행 중 `fetch`를
+후킹하면 SPA가 붙이는 `Authorization: Bearer ...` 헤더를 관찰할 수 있다.
+다만 persistent storage를 사용하지 않으므로 reload 이후 탈취 가능한 token
+복사본이 남지 않는다.
+
+`e2e/pattern1.mjs`는 다음 두 조건을 동시에 검증한다.
+
+1. access token이 Web Storage 어디에도 존재하지 않는다.
+2. 실행 중 fetch hook은 Bearer token을 관찰할 수 있다.
+
+따라서 결론은 “메모리면 XSS에 안전”이 아니라 “영속 탈취 범위를 줄이지만
+실행 중 XSS에는 여전히 노출”이다.