feat(S15P11A705-63): Google 소셜 로그인과 쿠키 기반 세션 JWT 도입

[cherry-go-round]

요약

Google 소셜 로그인과 쿠키 기반 세션 JWT를 도입합니다. OAuthLoginSuccessHandler가 회원만 확정하고 쿠키 없이 리다이렉트하던 자리(TODO(S15P11A705-63))를 채워, 발급·검증·회전·로그아웃 전체를 붙였습니다. 인증 계약(authentication.md)의 단일 PR 원칙에 따라 의존성·설정·테스트·문서를 함께 냅니다.

Jira (필수)

• 키 또는 URL: S15P11A705-63 — https://ssafy.atlassian.net/browse/S15P11A705-63

관련 GitHub Issue (선택)

• back#28 (인증 스텁 계약 — 이 PR에서 스텁을 제거하며 계약을 이어받음)

변경 사항

발급 (global/security/token)

• JwtTokenProvider — RS256 서명. sub·iss·exp·jti·token_use 클레임
• JwtKeyProvider — PKCS#8 PEM 주입. 공개키는 개인키(CRT)에서 유도해 설정 항목을 늘리지 않음. 키가 없으면 로컬·테스트는 임시 키쌍, 운영 프로파일은 기동 실패
• AuthCookies — access_token(Path=/api/core) · refresh_token(Path=/api/core/v1/auth) · logged_in(Path=/, HttpOnly 아님)

검증 (global/security/authentication)

• JwtAuthenticationFilter — Access 쿠키 → SecurityContext. 실패해도 401을 여기서 쓰지 않고 컨텍스트를 비운 채 통과시켜 오류 응답 형식을 한 곳(entry point)에 유지
• 검증 알고리즘을 RS256으로 고정(RFC 8725 §3.1). 토큰 헤더의 alg를 신뢰하지 않음
• MemberPrincipal·@LoginMember·LoginMemberArgumentResolver — principal 계약

회전 (domain/auth)

• RefreshTokenStore — jti당 Redis 키 하나. 소비는 delete의 반환값으로 판정(조회 후 삭제로 나누면 두 요청이 같은 토큰을 동시에 통과)
• POST /v1/auth/refresh(204, 회전) · POST /v1/auth/logout(204, 멱등)

설정·구조

• global/security를 책임별 하위 패키지 넷으로 분리 — oauth(공급자와의 흐름) / token(발급) / authentication(요청 검증) / error(401·403 응답). 보안 설정도 global/config에서 이 아래로 이동
• CsrfCookieFilter 추가 — spa()의 CSRF 토큰이 지연 로딩이라 조회 요청에서 XSRF-TOKEN이 안 나가고, 그러면 클라이언트가 첫 상태 변경 요청에 넣을 토큰을 구할 방법이 없어 영영 403
• JSpecify @NullMarked를 global/config·domain/auth/**·security/**로 확대
• 테스트 컨테이너 기반을 IntegrationContainerSupport 하나로 통합(Postgres + Redis)

문서

• BD-29(@NullMarked 패키지 단위) · BD-30(인가 요청을 쿠키에) · BD-31(RS256·키 관리) · BI-17(구현 리포트) · BT-04(트러블슈팅)
• authentication.md §7 구현된 형태 / §8 로컬·테스트 인증 통과 절차, configuration.md에 JWT_PRIVATE_KEY, package-structure.md에 보안 패키지 경계

테스트 / 검증

• ./gradlew clean check --no-daemon
• DB 변경 시 PostgreSQL 통합 테스트
• migration 변경 시 빈 DB migration 테스트
• API 계약 변경 시 관련 문서 갱신
• 되돌리기 어려운 결정을 포함하면 docs/backend/decisions/에 BD 추가 또는 기존 BD 링크

RED — 구현 전, AuthTokenContractTests를 HTTP 경계로만 작성해(새 타입 참조 없이) 컴파일 실패가 아닌 실제 단언 실패를 먼저 확인했습니다.

$ ./gradlew test --tests '*AuthTokenContractTests*' --no-daemon
인증 토큰 계약 > 콜백이 Access·Refresh·logged_in 쿠키를 계약된 속성으로 내려준다 FAILED
8 tests completed, 7 failed          # "쿠키가 안 내려온다"
BUILD FAILED

logged_in Path 버그(BT-04)도 같은 방식으로 고정했습니다.

Expecting actual: "/api/core"
to be equal to:   "/"
[프론트는 루트 아래에서 실행된다. API 경로로 좁히면 이 쿠키는 쓸모가 없다]

GREEN

$ ./gradlew test --tests '*AuthTokenContractTests*' --tests '*JwtTokenProviderTest*' --tests '*JwtKeyProviderTest*' --no-daemon
BUILD SUCCESSFUL     # 25 tests

Regression — dev 병합 후 HEAD(fa68d3e)에서 실행.

$ ./gradlew clean check --no-daemon
BUILD SUCCESSFUL in 57s
tests: 223  failures: 0     # 이 PR 131개 + dev 도메인 92개

실제 Google 수동 검증 — 동의 화면이 사람의 브라우저를 요구해 CI에 넣을 수 없는 경로입니다(authentication.md §8).

• OIDC 경로가 동작합니다. 자동 테스트는 scope에서 openid를 빼고 돌아(서명된 id_token·JWKS 검증 우회) OidcUserService 경로에 커버리지가 0건이었습니다. 운영 설정은 openid,email입니다. 실제 계정으로 sub·email이 추출돼 core.social_account에 저장되는 것을 확인했습니다
• redirect_uri 정확 일치, PKCE S256, nonce 통과
• Secure 쿠키가 http://localhost에서 왕복됩니다 — 코드 주석에 주장만 있고 검증한 적 없던 지점
• 이 과정에서 BT-04를 발견했습니다

배경

토큰 모델은 BD-21이 공용 계약으로 확정한 것이고, 이 PR은 비어 있던 서명 알고리즘·키 관리를 BD-31로 정했습니다.

RS256을 고른 이유를 명확히 해둡니다 — IETF가 요구해서가 아닙니다. RFC 9068이 비대칭을 RECOMMENDED로 걸지만 그 이유가 *"리소스 서버가 검증 정보를 얻는 과정을 단순화"*이고, 발급자·검증자 분리를 전제합니다. 우리는 한 프로세스라 그 이유가 성립하지 않습니다. RFC 8725는 대칭/비대칭에 중립입니다.

실제 이유는 되돌리는 비용의 비대칭입니다. HS256으로 두면 나중에 검증자를 분리할 때 알고리즘·키 배포·발급된 토큰 호환을 한꺼번에 갈아야 하고, RS256이면 공개키를 넘기는 일만 남습니다. 지금 필요해서가 아니라 나중 마이그레이션을 피하려고 내는 선불이며, BD-31의 감수 항목에 "끝까지 한 프로세스로 운영하면 HS256으로 충분했다는 뜻이 된다" 도 함께 적었습니다.

리뷰 포인트

1. dev 통합 방식 — merge를 썼습니다. PR 스킬 4.2는 rebase를 지시하지만, 이 병합에는 의미 충돌이 5건(마이그레이션 번호, BD·BI 번호, 스텁 중복, YAML 중복 키, 테스트 기반 클래스 이름) 있어 21개 커밋에 걸쳐 반복 해소하는 위험이 컸습니다. 이 저장소에도 Merge branch 'dev' into feat/... 선례가 있습니다(c011cff). 판단이 다르면 알려주세요 — 되돌릴 수 있게 병합 전 상태를 태그로 보관 중입니다.

2. ⚠️ 마이그레이션 번호가 V3 → V4로 바뀌었습니다. dev의 V3__core_domain.sql과 충돌해서입니다(git은 충돌로 잡지 않지만 Flyway가 기동을 거부). 이 브랜치를 먼저 받아 V3=social_account가 적용된 로컬 DB는 checksum 검증에 걸립니다 — docker compose down -v로 초기화가 필요합니다. 공유 환경에 적용된 적은 없습니다.

3. AuthTestSupport.loginAs 본문만 바꿨습니다. 스텁을 만든 쪽이 "인증 PR은 이 메서드 본문만 바꾼다"고 계약해 둔 대로, spring-security-test의 authentication() + csrf()로 교체했더니 도메인 테스트 7개 파일·110여 개 호출부가 한 줄도 바뀌지 않았습니다. csrf()를 함께 넣은 것이 핵심입니다 — 없으면 post·patch·delete 테스트가 전부 403이 됩니다.

4. 로그아웃의 한계는 감수한 것입니다. Refresh만 무효화하므로 이미 발급된 Access는 최대 30분 유효합니다(BD-21의 "무효화 지연"). 즉시 차단이 요건이 되면 블랙리스트가 필요합니다.

5. PR이 큽니다 (소스 85개 + 문서). 인증 계약이 단일 PR 병합을 요구해서 쪼갤 수 없습니다. 커밋을 유형별로 나눠 뒀으니(feat → refactor ×4 → fix → merge) 커밋 단위로 보시는 편이 나을 수 있습니다.

미결 / 후속

• ⚠️ 인프라에 JWT_PRIVATE_KEY 주입 요청이 필요합니다. 없으면 운영 파드가 뜨지 않습니다(의도한 fail-fast — 임시 키를 만들면 파드마다 서명 키가 달라져 스케일아웃·재시작 때 전면 로그아웃). RSA 2048+ PKCS#8 PEM. 배포 전 필수입니다
• 공용 계약 Team-PinLog/docs의 static/08_API_명세.md §1.1·2.1·3.2~3.5 개정 — 별도 저장소라 이 PR 밖입니다
• 키 회전 — kid만 선반영했고 다중 키 검증은 없습니다. 지금 키를 바꾸면 전면 로그아웃입니다
• Kakao·Naver 소셜 로그인은 S15P11A705-64, 회원 탈퇴는 S15P11A705-65로 분리되어 있습니다

[minyongP]

리뷰

OAuthLoginSuccessHandler의 TODO 한 줄이었던 자리에 토큰 파이프라인 전체가 들어왔습니다. 전반적으로 완성도가 높고, 특히 JWT PR에서 흔히 빠지는 것들이 다 들어 있습니다.

• alg confusion 회귀 테스트 — 공개키를 HMAC 비밀로 삼은 HS256 위조 토큰 거부. 검증 알고리즘을 헤더의 alg가 아니라 JWSVerificationKeySelector에 RS256으로 고정한 것도 정확합니다.
• delete 반환값으로 소비 판정 — 조회 후 삭제로 나눴을 때의 경쟁 조건을 처음부터 피했습니다.
• token_use 분리를 HTTP 경계에서까지 고정 — AuthTokenContractTests.accessTokenIsNotAcceptedAsRefreshToken.
• Filter 빈의 서블릿 체인 이중 등록을 짚고 @Component를 뺀 판단.
• 60초 시계 오차 관용의 존재 자체를 테스트로 고정 — 발견하고 넘어간 게 아니라 계약으로 못 박았습니다.
• AuthTestSupport.loginAs 본문만 바꿔 호출부 110여 개를 그대로 둔 것. back#28 계약이 실제로 값을 했습니다.

아래는 병합 전에 손봐야 한다고 보는 것들입니다.

---

🔴 반드시 고쳐야 함

1. XSRF-TOKEN 쿠키가 Path=/api/core로 나갑니다 — BT-04와 같은 버그입니다

CsrfConfigurer.spa()는 CookieCsrfTokenRepository.withHttpOnlyFalse()를 cookiePath 설정 없이 씁니다. Security 7.0.x의 saveToken은 이렇게 동작합니다.

.path(StringUtils.hasLength(this.cookiePath) ? this.cookiePath : this.getRequestContext(request))
// getRequestContext → contextPath.length() > 0 ? contextPath : "/"

server.servlet.context-path: /api/core이므로 XSRF-TOKEN은 Path=/api/core로 저장됩니다. 프론트는 /·/auth/callback 아래에서 도는데(client-redirect-uri: /auth/callback, "프론트와 같은 오리진"), 그 페이지의 document.cookie에는 Path=/api/core 쿠키가 나타나지 않습니다. 즉 클라이언트는 X-XSRF-TOKEN에 넣을 값을 읽을 수 없고, 모든 상태 변경 요청이 영영 403이 됩니다.

CsrfCookieFilter가 해결한 문제(쿠키가 안 나가는 것)와는 다른 층위입니다. 쿠키는 나가지만 프론트가 읽지 못합니다. BT-04에서 logged_in을 두고 정확히 같은 판단을 내렸는데 XSRF-TOKEN에는 적용되지 않았습니다.

SecurityConfig에서:

CookieCsrfTokenRepository csrfTokenRepository = CookieCsrfTokenRepository.withHttpOnlyFalse();
csrfTokenRepository.setCookiePath("/");   // 프론트가 읽어야 한다. BT-04와 같은 이유
...
.csrf(csrf -> csrf
    .csrfTokenRepository(csrfTokenRepository)
    .csrfTokenRequestHandler(new SpaCsrfTokenRequestHandler()))

테스트가 이걸 못 잡는 이유도 같이 봐야 합니다. AuthTokenContractTests.postWithCsrf는 Set-Cookie 헤더 원문에서 값을 꺼내므로 브라우저의 Path 범위 제한을 우회합니다. logged_in에 붙인 것과 같은 단언을 추가하면 고정됩니다.

assertThat(attribute(setCookie(response, CSRF_COOKIE), "Path"))
    .as("프론트가 document.cookie로 읽어야 한다. API 경로로 좁히면 헤더에 넣을 값을 구할 수 없다")
    .isEqualTo("/");

2. OAuthLoginSuccessHandler에 오류 경로가 없습니다

onAuthenticationSuccess는 필터 체인 안에서 돌아 @RestControllerAdvice를 타지 않습니다(SecurityErrorWriter 주석이 이미 이 사실을 알고 있죠). 그런데 이 안에서 세 갈래로 예외가 나갈 수 있습니다.

• OAuthUserInfo.from → UnsupportedSocialProviderException(KAKAO·NAVER), IllegalStateException(sub 없음)
• SocialLoginService.signUp → DataIntegrityViolationException. 같은 소셜 계정의 첫 로그인이 동시에 두 번 들어오면 ux_social_account_provider_user 부분 유니크에 걸립니다. 확률은 낮지만 더블클릭 정도로도 재현 가능합니다.

셋 다 지금은 톰캣 기본 500 페이지로 나갑니다 — 공통 envelope도 아니고, 명세가 정한 /auth/callback?error=OAUTH_FAILED 복귀도 아닙니다. 성공 핸들러 본문을 감싸 실패 핸들러와 같은 경로로 보내는 게 맞습니다. signUp 쪽은 DataIntegrityViolationException을 잡아 재조회로 흡수하면 사용자 눈에는 정상 로그인이 됩니다.

---

🟡 논의가 필요함

3. Refresh 재사용 감지가 세션 계열을 끊지 않습니다

rotate는 소비된 jti에 401만 돌려줍니다. 토큰이 유출된 상황을 보면, 공격자가 먼저 회전하면 정상 사용자가 401을 받고 공격자의 새 토큰은 살아 있습니다. RFC 9700 §4.14.2가 재사용 감지 시 해당 사용자의 refresh 토큰 전부를 폐기하라고 하는 게 이 시나리오 때문입니다.

jti당 키 하나 구조라 전부 지우려면 auth:refresh:<memberId>:* SCAN이 필요한데, 회원당 Set을 하나 더 두고 jti를 담으면 O(1)로 끊을 수 있습니다. 지금 안 하겠다면 최소한 재사용 감지를 WARN으로 남기고, BD-21 감수 항목에 "재사용 감지 시 계열 폐기는 하지 않는다"를 명시해 두는 편이 낫습니다. 지금은 로그아웃 한계만 적혀 있어 이 구멍이 문서에 안 보입니다.

4. ObjectInputFilter에 자원 한도가 없습니다

"org.springframework.security.oauth2.core.**;java.util.**;java.lang.**;!*"

클래스 기반 gadget 체인은 잘 막았습니다. 다만 java.util.**이 열려 있으면 중첩 HashSet/HashMap 해시 증폭(SerialDOS)이 그대로 통과합니다 — readObject가 hashCode()를 재귀 호출해서, 수 KB짜리 쿠키 하나로 CPU를 수 분간 태울 수 있습니다. 이 경로는 인증 이전에 돌고 입력은 전적으로 클라이언트가 줍니다.

한도만 앞에 붙이면 닫힙니다.

ObjectInputFilter.Config.createFilter(
    "maxdepth=20;maxrefs=1000;maxbytes=8192;maxarray=1000;"
        + "org.springframework.security.oauth2.core.**;java.util.**;java.lang.**;!*");

부수적으로 이 쿠키에는 무결성 보호(MAC)가 없습니다. HttpOnly라 JS로는 못 건드리지만 같은 오리진에 쿠키를 심을 수 있는 상황이면 인가 요청을 갈아끼울 수 있습니다. 한도 추가보다 우선순위는 낮으니 후속으로 봐도 됩니다.

5. 탈퇴한 회원의 세션이 살아 있습니다

JwtAuthenticationFilter도 rotate도 회원이 아직 활성인지 보지 않습니다. 무상태 설계상 Access 30분은 감수 항목이 맞지만, rotate는 회원 확인 없이 계속 새 토큰을 내주므로 탈퇴한 회원이 7일마다 세션을 무한히 갱신할 수 있습니다. 탈퇴 티켓(S15P11A705-65)의 완료 조건에 "탈퇴 시 auth:refresh:<memberId>:* 폐기"를 넣어 두면 여기서 새지 않습니다. 이 PR에서 고칠 일은 아니지만 티켓 간 의존으로 남겨야 합니다.

---

🟢 사소한 것

• SocialAccount.create(..., String email) — SocialLoginService(@NullMarked)가 @Nullable인 userInfo.email()을 그대로 넘깁니다. domain/member/entity가 아직 @NullMarked가 아니라 지금은 컴파일되지만, BD-29가 말하는 확대 방향대로 가면 깨집니다. 지금 @Nullable String email로 표시해 두는 게 쌉니다.
• logged_in 수명이 7일인데 Access는 30분입니다. 30분 방치한 탭은 재발급이 돌기 전까지 로그인 상태로 표시됩니다. 의도한 것이면 AuthCookies 주석에 한 줄 남겨 주세요.
• IntegrationContainerSupport의 static 블록 주석만 영어입니다. 나머지 파일 전체가 한국어라 눈에 띕니다.

---

리뷰 포인트에 대한 답

1. merge vs rebase — 21개 커밋 × 의미 충돌 5건이면 rebase 비용이 실제로 더 큽니다. c011cff 선례도 있고 병합 전 태그도 잡아 뒀으니 이대로 갑니다.
2. V3 → V4 — 맞는 판단입니다. docker compose down -v 안내가 본문에 있으니 충분합니다.
3. loginAs 본문만 교체 — 이 PR에서 값이 가장 잘 드러난 지점입니다. csrf()를 함께 넣은 이유까지 주석에 남긴 것도 좋습니다.
4. 로그아웃 한계 — 문서화된 감수 항목이라 받아들입니다. 다만 위 3번은 같은 문서에 아직 안 적혀 있습니다.
5. PR 크기 — 인증 계약상 쪼갤 수 없는 게 맞습니다. 커밋 유형별 분리가 도움이 됐습니다.

---

1번(CSRF 쿠키 Path)과 2번(성공 핸들러 오류 경로)을 고치면 병합해도 된다고 봅니다. 1번은 프론트를 붙이는 순간 전면 403으로 드러날 것이라 배포 전에 반드시 잡아야 하고, 고치는 비용도 두 줄입니다. 3·4번은 코드로 처리하든 BD-21/BD-31 감수 항목에 명시하든 둘 중 하나는 필요합니다. 5번 이하는 후속으로 충분합니다.

[minyongP]

총평

병합에 반대하지 않습니다. 보안 핵심을 정확히 짚었습니다 — 검증 알고리즘 RS256 고정(RFC 8725, alg confusion 차단 테스트까지 있음), PKCE 명시 활성화, Refresh 회전을 delete 반환값 하나로 원자적으로 판정, 운영 키 미주입 시 fail-fast. 테스트가 HTTP 경계 계약으로 작성되어 있어 내부 리팩터링에 흔들리지 않는 점도 좋습니다. 아래는 정리 항목과 동작 관련 검토 요청입니다.

반드시 정리 (이 PR에서)

1. 죽은 프로퍼티 pinlog.auth.stub.enabled=true가 테스트 6곳에 남아 있습니다.

• CollectionApiTests, PublicCollectionApiTests, FollowApiTests, DeletionApiTests, RecordApiTests, RecordMapApiTests

스텁이 이 PR에서 제거되어 이 프로퍼티는 어디에도 바인딩되지 않습니다. 남겨두면 "스텁이 아직 있다"는 거짓 신호가 되고, 스텁 계약(back#28)이 요구한 "프로퍼티를 반드시 제거한다"의 마지막 조각이기도 합니다. 같은 파일의 management.health.redis.enabled=false도 IntegrationContainerSupport가 Redis를 항상 띄우는 지금은 이유가 사라졌으니 함께 정리하면 좋겠습니다.

검토 요청 (동작)

2. 신규 가입 동시성 — 콜백 경합이 사용자에게 500으로 나갑니다.

SocialLoginService.login()은 조회 → 없으면 가입인데, 같은 신규 사용자의 콜백 두 개가 동시에 들어오면 둘 다 조회를 비켜가고 한쪽이 부분 유니크 인덱스(ux_social_account_provider_user) 위반으로 터집니다. 이 예외는 성공 핸들러 밖으로 나가므로 실패 핸들러(OAUTH_FAILED 리다이렉트)를 타지 않고 500이 됩니다. #69에서 중복 팔로우 경합을 409로 바꾼 것과 같은 종류의 문제입니다. DataIntegrityViolationException을 잡아 재조회로 로그인 처리하면 사용자는 그냥 로그인됩니다.

3. 인가 요청 쿠키 수명 180초가 실사용에 빠듯할 수 있습니다.

Google 화면에서 계정 선택 + 비밀번호 재입력 + 2단계 인증을 거치면 3분을 넘기는 경우가 실제로 있습니다. 넘기면 콜백에서 인가 요청을 못 찾아 OAUTH_FAILED로 돌아오고, 사용자는 이유를 모른 채 재로그인하게 됩니다. 300~600초를 고려해 주세요.

4. 인가 요청 쿠키의 Java 직렬화는 Spring Security 버전 업그레이드 순간 왕복 중 로그인을 깨뜨립니다.

역직렬화 필터를 건 것은 좋습니다. 다만 OAuth2AuthorizationRequest의 Java 직렬화 형식은 버전 간 호환이 보장되지 않아, 라이브러리를 올려 배포하는 순간 진행 중이던 로그인 왕복은 전부 실패합니다(재로그인 유도로 끝나므로 치명적이진 않음). 필요한 필드만 뽑아 JSON으로 담으면 이 결합이 없어집니다 — 후속으로 충분합니다.

5. Redis가 로그인·재발급의 경성 의존이 됐습니다.

Redis 순단 시 로그인 콜백과 /v1/auth/refresh가 500이 됩니다. BD-28대로 readiness에는 Redis가 없으므로 파드는 정상인데 로그인만 전부 실패하는 상태가 됩니다. 이미 발급된 Access(최대 30분)는 계속 동작하므로 감수할 만하지만, 의도한 감수라는 것을 BD-21이나 BI-18에 한 줄 남겨두면 장애 때 판단이 빨라집니다.

병합·배포 전 확인 (PR 본문 재확인)

• 인프라 선행: JWT_PRIVATE_KEY 미주입 시 운영 파드 기동 실패(의도된 fail-fast). GOOGLE_CLIENT_ID/SECRET 미주입 시 기동은 되지만 로그인 불가(client_id=unset으로 Google에서 거절). 다음 운영 배포 전에 Secret 주입이 선행돼야 합니다.
• 프론트 선행: 모든 상태 변경 요청에 X-XSRF-TOKEN 헤더 필수(없으면 403), 미인증 응답 404 → 401 변경, X-Debug-Member-Id 폐지. 공유 dev 환경에 배포되기 전에 프론트가 준비돼야 합니다.

사소

• AuthenticatedTestController는 javadoc대로 실제 me API가 병합되면 제거 대상입니다. 해당 도메인 티켓에 메모를 남겨두면 잊지 않습니다.

리뷰 포인트에 대한 답

• merge vs rebase(포인트 1): merge 판단에 동의합니다. 의미 충돌 5건을 21개 커밋에 걸쳐 반복 해소하는 비용·위험이 더 크고, 저장소에 선례(c011cff)도 있습니다.
• V3 → V4(포인트 2): 번호 정리는 맞습니다. 이 브랜치의 옛 V3(social_account)를 로컬에 적용했던 사람만 docker compose down -v가 필요하고, 공유 환경엔 영향이 없다는 정리도 정확합니다.

[cherry-go-round]

리뷰 두 건 모두 반영했습니다 — 628d674. ./gradlew clean check --no-daemon 226개 통과, 실패 0.

🔴 고쳤습니다

1. XSRF-TOKEN 쿠키 Path — 지적이 정확했고, 실증했습니다

실행 중인 앱에 curl로 확인한 실제 헤더입니다.

Set-Cookie: XSRF-TOKEN=4d9c660b-4e0c-4584-8c2d-070db14ba251; Path=/api/core

BT-04에서 logged_in에 내린 판단을 CSRF 쿠키에는 적용하지 않았습니다. 프론트를 붙이는 순간 전면 403이 될 버그였습니다.

spa()의 요청 핸들러가 CsrfConfigurer 내부 클래스라 직접 지정할 수 없어서, 제안해 주신 형태 대신 spa()를 부른 뒤 저장소만 덮어쓰는 순서로 갔습니다.

.csrf(csrf -> csrf
    .spa()
    .csrfTokenRepository(csrfTokenRepository))   // Path=/ 로 설정된 것

"테스트가 이걸 못 잡는 이유도 같이 봐야 합니다" — 그 지적이 이번 리뷰에서 가장 값이 컸습니다. postWithCsrf가 Set-Cookie 원문에서 값을 꺼내 브라우저의 Path 제한을 우회하고 있었습니다. 제안하신 단언을 그대로 추가했고, 고치기 전 expected "/" but was "/api/core"로 실패하는 것을 먼저 확인했습니다.

2. 성공 핸들러 오류 경로

본문을 감싸 실패 핸들러로 보냅니다. 두 리뷰가 같이 짚은 신규 가입 동시성도 여기서 흡수합니다.

ON CONFLICT(BI-14)가 아니라 재시도를 택한 이유를 적어둡니다 — 성공 핸들러는 @Transactional 밖이라 재호출이 프록시를 타고 새 트랜잭션을 엽니다. BI-14가 예외를 안 잡은 이유(같은 트랜잭션은 rollback-only)가 여기엔 해당하지 않습니다. 진 쪽은 트랜잭션이 통째로 롤백되므로 고아 회원도 남지 않습니다.

테스트를 짜다 하나 알게 됐습니다. 빈 sub로 트리거하려 했더니 Spring 내부(OAuth2AuthorizedClient 생성)에서 IllegalArgumentException으로 먼저 죽어 우리 핸들러에 도달하지 않습니다. AbstractAuthenticationProcessingFilter는 AuthenticationException만 실패 핸들러로 넘기므로 이 경로는 감쌀 자리가 없습니다. 한계로 BI-18에 기록했고, 테스트 트리거는 email VARCHAR(255) 초과로 바꿨습니다.

🟡 코드로 처리

항목	처리
역직렬화 자원 한도	maxdepth=20;maxrefs=1000;maxbytes=8192;maxarray=1000 추가. 인증 이전에 도는 경로이고 입력이 전적으로 클라이언트 것이라 지적대로 위험이 실재합니다
인가 요청 쿠키 수명	180초 → 600초. 2단계 인증까지 거치면 3분이 빠듯하다는 지적에 동의합니다
죽은 pinlog.auth.stub.enabled	6곳 제거. back#28 계약의 마지막 조각이었습니다
management.health.redis.enabled=false	12곳 제거. ReadinessProbe* 둘은 유지했습니다 — 하나는 =true로 Redis 장애를 재현하고, 하나는 DB 장애를 격리하려고 끈 것이라 의도적입니다
@Nullable email, logged_in 수명 주석, 영어 주석	반영

🟡 문서로 명시 (BD-32 신설)

Refresh 재사용 시 계열 폐기를 하지 않는다는 사실을 BD-32로 남기고 감지 WARN을 추가했습니다. 지적하신 유출 시나리오(공격자가 먼저 회전 → 정상 사용자만 끊김)를 그대로 적었습니다.

"위험이 작아서 미루는 것이 아니라 PR 크기 때문" 이라고 명시했고, 재검토 트리거로 탈퇴 티켓(S15P11A705-65)과 같은 자료구조(회원당 Set)가 필요하니 함께 하는 것이 자연스럽다를 넣었습니다.

BI-18에는 Redis가 로그인·재발급의 경성 의존이 된 것(BD-28대로 readiness에 Redis가 없어 파드는 Ready인데 로그인만 실패하는 증상)과 Java 직렬화의 버전 결합을 감수 항목으로 적었습니다. 장애 때 원인 찾는 시간을 줄이자는 취지 그대로입니다.

후속으로 남깁니다

• 인가 요청 쿠키를 JSON으로 전환 (Java 직렬화 결합 제거)
• 탈퇴 시 auth:refresh:<memberId>:* 폐기를 S15P11A705-65 완료 조건에 추가 — 지적대로 티켓 간 의존으로 남깁니다
• AuthenticatedTestController 제거를 me API 티켓에 메모

배포 선행 조건 (재확인 감사합니다)

• 인프라: JWT_PRIVATE_KEY 미주입 시 운영 파드 기동 실패(의도된 fail-fast). GOOGLE_CLIENT_ID/SECRET은 기동은 되나 로그인 불가
• 프론트: 상태 변경 요청에 X-XSRF-TOKEN 필수, 미인증 404 → 401, X-Debug-Member-Id 폐지. 위 1번을 고치기 전이었다면 프론트가 토큰을 읽을 수조차 없었습니다

[minyongP]

628d674 확인했습니다. 지적한 항목은 전부 처리됐고(죽은 프로퍼티 6곳 grep 0건, 동시성 흡수, 쿠키 수명 600초, BI-18 감수 기록), 제가 놓친 CSRF 쿠키 Path 버그를 찾아낸 것과 테스트가 왜 그걸 못 잡았는지(postWithCsrf가 Set-Cookie 원문을 읽어 브라우저 Path 제한을 우회)까지 같이 고친 것이 이번 커밋에서 가장 값있는 부분이라고 봅니다. 통과하는 테스트가 거짓 보증이던 자리를 찾은 것이니까요.

병합에 반대하지 않습니다. 아래 두 개는 후속으로 충분한 항목이고, 기록으로 남깁니다.

1. SecurityContractTests가 존재하지 않는 경로를 검증합니다

SecurityContractTests.java:54·60이 /api/core/v1/me/summary를 때리는데 이 경로는 아직 구현되지 않았습니다. /me/summary는 명세 3.5에 있지만 컨트롤러가 없습니다.

@DisplayName("보호 경로에 인증 없이 접근하면 401을 반환한다")
void protectedPathReturnsUnauthorized() throws Exception {
    assertThat(get("/api/core/v1/me/summary").statusCode()).isEqualTo(401);
}

그래서 이 테스트가 실제로 검증하는 것은 "매핑되지 않은 경로도 401"이고, DeploymentContractTests.unmappedServiceUrlRequiresAuthentication과 같은 내용입니다. 실제 도메인 엔드포인트가 실수로 permitAll에 들어가도 이 테스트는 그대로 통과합니다 — 이름이 약속하는 계약을 지키지 못합니다.

/api/core/v1/collections나 /api/core/v1/records/map처럼 매핑된 엔드포인트로 바꾸면 됩니다. 401 envelope를 보는 두 번째 테스트도 같은 경로를 쓰므로 함께 바꾸면 됩니다.

CSRF Path 버그와 같은 종류의 문제입니다 — 테스트가 통과하는데 검증 대상이 실제와 다른 자리요.

2. CSRF 쿠키의 Secure만 환경 의존입니다

SecurityConfig.java:88의 CookieCsrfTokenRepository는 secure를 지정하지 않았습니다. 이 경우 Spring은 request.isSecure()를 따르므로, 운영에서 Secure가 붙는 것이 Traefik의 X-Forwarded-Proto가 정확히 오는 것에 의존하게 됩니다.

AuthCookies는 같은 판단을 다르게 내렸습니다.

return ResponseCookie.from(name, value).secure(true)...

javadoc에 근거까지 적혀 있습니다 — "브라우저는 http://localhost를 신뢰할 수 있는 오리진으로 취급해 Secure 쿠키를 그대로 보내므로, 로컬 전용 예외를 두면 운영과 다른 경로를 검증하게 될 뿐이다." 그 논리가 CSRF 쿠키에도 그대로 적용됩니다.

새로 추가한 csrfCookieIsReadableFromClientPages도 Path와 HttpOnly만 단언하고 Secure는 보지 않아서, 이 속성은 지금 테스트로 고정되지 않은 상태입니다.

CookieCsrfTokenRepository repository = CookieCsrfTokenRepository.withHttpOnlyFalse();
repository.setCookiePath("/");
repository.setSecure(true);   // AuthCookies와 같은 이유

setSecure(true) 한 줄과 단언 하나로 forward-headers-strategy 설정에 대한 의존이 사라집니다. 보안 속성이 인프라 설정 하나에 걸려 있지 않은 편이 낫습니다.

---

둘 다 병합 후 별도 커밋으로 처리해도 무방합니다. 배포 조건(인프라 JWT_PRIVATE_KEY·Google Secret 선행, 프론트 X-XSRF-TOKEN 준비)은 앞선 리뷰와 같습니다.

[cherry-go-round]

두 건 모두 반영했습니다 — d462891. ./gradlew clean check --no-daemon 226개 통과, 실패 0.

두 항목 다 후속으로도 무방하다고 하셨지만, 1번은 "통과하는데 검증 대상이 다른" 테스트를 알면서 병합하는 셈이라 지금 처리했습니다. 직전 커밋에서 같은 종류를 잡아 놓고 새로 하나를 남겨두는 게 이상해서요.

---

1. 보호 경로 테스트 — 고쳤습니다. 다만 근거는 절반만 맞았습니다

/v1/me/summary가 구현되어 있지 않다는 것, 그래서 실제로 검증된 게 DeploymentContractTests와 같은 내용이었다는 것 — 맞습니다. /v1/collections로 바꿨습니다.

그런데 "실제 도메인 엔드포인트가 실수로 permitAll에 들어가도 이 테스트는 그대로 통과합니다" 를 그대로 받지 않고 실험했습니다. /v1/collections를 임시로 permitAll에 넣고 돌렸더니 — 경로를 바꾼 뒤에도 통과합니다.

원인은 LoginMemberArgumentResolver가 fail-closed라서입니다.

Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
if (authentication == null || !authentication.isAuthenticated()) {
    throw new UnauthorizedException();
}

인가 규칙을 뚫어도 리졸버가 401을 던집니다. 그 클래스 javadoc에 적어둔 의도가 그대로 작동한 겁니다 — "나중에 공개 경로가 늘었을 때 principal이 조용히 null로 들어가는 편보다 401로 끊기는 편이 안전하다."

그래서 permitAll 실수를 막는 건 이 테스트가 아니라 리졸버입니다. 방어가 두 겹이고, 응답만 봐서는 어느 쪽이 막았는지 구분되지 않습니다(둘 다 UNAUTHORIZED envelope).

이 테스트가 고정하는 것은 바깥에서 관측 가능한 계약 — 실재하는 보호 경로에 미인증으로 들어가면 401이 공통 envelope로 나온다 — 이고, 어느 층이 막았는지는 계약이 아닙니다. 그 내용을 상수 javadoc에 적었습니다.

참고로 저도 처음엔 지적하신 문장을 그대로 옮겨 "이제 permitAll을 잡는다" 고 javadoc에 썼다가, 위 실험으로 스스로 반증하고 고쳤습니다.

만약 "인가 규칙 자체"를 격리해서 검증하고 싶다면 별도 방법이 필요합니다. @LoginMember를 받지 않는 보호 엔드포인트가 없어서 지금은 리졸버를 우회할 방법이 없고, 그런 엔드포인트를 테스트용으로 만드는 건 과해 보입니다. 필요하다고 보시면 후속으로 논의하겠습니다.

2. CSRF 쿠키 Secure — 고쳤습니다. 제안하신 API는 없어서 다른 경로로 갔습니다

request.isSecure() 위임은 saveToken 소스로 확인했고, 실제 응답도 Secure가 없었습니다.

Set-Cookie: XSRF-TOKEN=012049d7-...; Path=/

AuthCookies가 같은 이유로 이미 secure(true)를 고정하고 있는데 CSRF 쿠키만 환경에 맡겨 둔 게 일관되지 않다는 지적, 그대로 동의합니다.

다만 repository.setSecure(true)는 Spring Security 7.1.0에 없습니다. CookieCsrfTokenRepository의 공개 API는 이것뿐입니다.

setCookieName / setCookiePath / setParameterName / setHeaderName / setCookieCustomizer

setCookieCustomizer가 유일한 경로이고, 소스상 기본값을 적용한 뒤에 실행되어 덮어쓸 수 있습니다(saveToken에서 .secure(...) 다음 줄이 cookieCustomizer.accept(cookieBuilder)).

CookieCsrfTokenRepository repository = CookieCsrfTokenRepository.withHttpOnlyFalse();
repository.setCookiePath("/");
repository.setCookieCustomizer(cookie -> cookie.secure(true).sameSite("Lax"));

SameSite도 함께 넣었습니다. 지적 항목은 아니었는데, 위 응답에서 보이듯 CSRF 쿠키에만 빠져 있었습니다. AuthCookies는 셋 다 SameSite=Lax를 붙이므로 같은 논리가 적용됩니다. 이제 네 쿠키가 모두 같은 규칙을 따릅니다.

RED는 Path=/는 적용됐고 Secure가 없는 상태로 먼저 확인했습니다.

---

배포 선행 조건(인프라 JWT_PRIVATE_KEY·Google Secret, 프론트 X-XSRF-TOKEN 준비)은 앞선 리뷰와 같고 변동 없습니다.