[IMPROVE] OAuth 성공 redirect access token 제거 및 refresh 연동

[Dimo-2562]

Parent: #426
Related: #431, #433

✨ 개선할 기능

OAuth 성공 redirect URL에서 access token을 제거하고, 프론트 callback이 HttpOnly refresh token cookie 기반으로 /api/v1/auth/refresh를 호출해 access token을 획득하도록 로그인 완료 흐름을 변경한다.

🏷️ 도메인 (해당하는 것에 체크)

• 📝 domain:post (게시글)
• 👤 domain:useraccount (사용자 계정)
• 🧠 domain:personalization (개인화 프로필)
• 🏢 domain:source (테크블로그 출처)
• 🔍 domain:search (검색)
• 🔔 domain:notification (알림)
• 📊 domain:recommendation (추천)
• 🎯 domain:activity (사용자 활동)
• 🔐 domain:auth (인증/보안)
• 🌐 infra (인프라/배포)

📌 현재 상태 (AS-IS)

• OAuth 성공 redirect URL이 access token을 query parameter로 포함한다.
• 이 값은 브라우저 히스토리, referrer header, 프론트 로그/analytics/에러 리포트에 노출될 수 있다.
• #431은 책임 분리 리팩터링 이슈라 기존 token wire shape과 redirect 동작을 최대한 유지한다.
• 현재 서버에는 이미 refresh token cookie만으로 access token을 재발급하는 POST /api/v1/auth/refresh가 있다.
  • /api/v1/auth/**는 public endpoint다.
  • refresh API는 Authorization header가 아니라 refreshToken cookie를 사용한다.

🎯 개선 방향 (TO-BE)

• OAuth 성공 handler는 refresh token을 기존처럼 HttpOnly Secure cookie로 설정한다.
• OAuth 성공 redirect URL에서는 access token을 제거한다.
• redirect URL에는 최소한의 callback 상태만 남긴다.
  • 예: registered, email 등 프론트가 필요한 비토큰 값
• 프론트 callback 페이지는 redirect 후 POST /api/v1/auth/refresh를 credentials: include로 호출해 access token을 받는다.
• 프론트/백엔드 계약 변경이 필요하므로 #431과 분리해서 진행한다.

💡 개선 이유

• bearer access token은 URL에 담기 적합하지 않다.
• refresh token은 이미 HttpOnly cookie로 전달되므로 OAuth callback 이후 access token 발급은 기존 refresh API를 재사용하는 것이 더 안전하다.
• 프론트 callback 로직 변경이 필요해 리팩터링 PR과 별도 이슈로 추적한다.

✅ 완료 조건

• OAuth 성공 redirect URL에서 access token 제거
• OAuth success redirect factory/handler 테스트 갱신
• 프론트 callback에서 POST /api/v1/auth/refresh 호출하도록 연동 확인
• cookie 포함 요청(credentials: include) 동작 확인
• 로그인 완료 후 ACTIVE/PENDING 사용자 흐름 확인
• 기존 refresh/logout API 회귀 테스트 통과

참고

• [REFACTOR] OAuth/OIDC 보안 인프라 책임 분리 #431 코드 리뷰 중 HIGH 보안 이슈로 식별됨.
• #433은 실패 redirect와 OAuth state cookie 보안 속성을 주로 다루므로, 성공 redirect의 access token 제거는 별도 이슈로 분리한다.

🔗 Redirect URL 계약 정리

#431 리뷰에서 success redirect URL이 String.format(...)의 positional placeholder에 의존한다는 WATCH 항목도 확인되었다.
#440에서 access token을 redirect URL에서 제거할 때 함께 정리한다.

• %s 순서에 의존하는 jwt.redirect-uri template 사용을 줄인다.
• success redirect 입력은 typed request/value object로 명시한다.
  • 예: registered, email 등 callback에 남길 비토큰 값
• URL 조립은 가능하면 UriComponentsBuilder 기반으로 query parameter 이름을 코드에 드러낸다.
• 필요하면 jwt.redirect-uri를 OAuth success redirect 전용 base URI property로 분리한다.

✅ 추가 완료 조건

• success redirect URL 조립에서 positional String.format(...) 의존 제거 또는 typed redirect request로 의미 명시
• [IMPROVE] OAuth 성공 redirect access token 제거 및 refresh 연동 #440 변경 후 redirect URL contract 테스트 갱신