# 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에는 여전히 노출”이다.