keycloak-pattern/docs/ap1-token-storage.md

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