웹, 어드민이 같은 refresh token을 사용함으로 인해 발생하는 문제를 어떻게 해결할까 ?

[whqtker]

문제

배경

현재 production 환경에서 refresh token 이름이 고정되어 있습니다.

token:
refresh:
cookie-name: "prodRefreshToken"cookie-domain: ".solid-connection.com"

다음과 같은 문제가 발생할 수 있습니다.

1. www.solid-connection.com에서 개인 계정 로그인
2. 브라우저에 .solid-connection.com 범위의 prodRefreshToken 저장
3. www.admins.solid-connection.com 접속
4. 어드민 페이지가 토큰 자동 재발급 요청
5. 같은 prodRefreshToken이 api.solid-connection.com으로 전송됨
6. 서버는 개인 계정 access token을 재발급
7. /admin/** 요청에서 ROLE_ADMIN이 없어 403

고려 중인 방향

request 헤더 기준 분기

HTTP 요청에서 Origin 헤더가 https://www.admins.solid-connection.com이면 adminRefreshToken, https://www.solid-connection.com이면 prodRefreshToken을 사용하도록
아니면 별도의 헤더를 사용하도록 (e.g. X-Client-Type: admin)

헤더를 명시적으로 붙여야 함
Nginx 프록시를 통함에 있어 잠재적 문제가 발생할 수 있음

별도 엔드포인트

/admin/auth/reissue처럼 별도 어드민용 토큰 재발급 엔드포인트 만들기

별도 API를 작성해야 함

[Hexeong]

작성해주신 내용 잘 읽었습니다. 제 생각은 아래와 같습니다.

제안 : 별도 엔드포인트 분리 방법

핵심 의견

권한 수준이 다른 두 클라이언트(일반 사용자 / 어드민)가 같은 토큰 재발급 엔드포인트를 공유하는 것은, 자칫 잘못된 권한의 토큰이 발급되는 문제 지점이 될 수 있습니다.

방어적 코드 관점에서, 권한이 다른 두 흐름은 처음부터 엔드포인트를 분리해 각자의 맥락에서만 동작하도록 보장하는 것이 맞다고 생각합니다.

구체적 방안

구분	현재	변경 후
웹 reissue	POST /auth/reissue → prodRefreshToken 쿠키	유지
어드민 reissue	(없음, 웹과 동일 엔드포인트 사용)	POST /admin/auth/reissue → adminProdRefreshToken 쿠키
어드민 로그인	POST /auth/email/sign-in → prodRefreshToken 발급	POST /admin/auth/sign-in 등 → adminProdRefreshToken 발급
Redis 키	REFRESH:{userId} 단일	WEB_REFRESH:{userId} / ADMIN_REFRESH:{userId} 분리

이 방식의 장점

• /admin/auth/reissue에서 ROLE_ADMIN 검증을 추가할 수 있어,
  일반 사용자 토큰으로 어드민 재발급 시도 시 즉시 차단 가능
• 이미 SecurityConfig에서 /admin/**는 hasRole(ADMIN)으로 보호 중 →
  기존 보안 레이어와 자연스럽게 일치
• Origin 헤더 신뢰 여부나 nginx 설정에 의존하지 않아 안정적

Origin 헤더 기반 분기를 선택하지 않는 이유

• Origin 헤더는 서버가 클라이언트를 신뢰해서 분기하는 방식 → 방어적이지 않음
• 같은 엔드포인트 안에서 if/else로 권한 흐름을 나누면,
  조건이 누락되거나 헤더가 없는 경우 잘못된 쪽 경로가 실행될 위험이 있음
• 엔드포인트를 분리하면 이런 실수 가능성 자체가 없어짐

---

변경 범위 (참고)

1. RefreshTokenCookieProperties — 웹/어드민 쿠키 이름 분리
2. Redis 토큰 저장 키 분리 (TokenStorage 수정)
3. 어드민 로그인 시 adminProdRefreshToken 발급하는 흐름 추가
4. POST /admin/auth/reissue 신규 엔드포인트 작성 + ROLE_ADMIN 검증

[whqtker]

흠 별도 API 없이 해결하고 싶었는데 이 방법이 가장 깔끔한 건 어쩔 수 없나 보네용

의견 감사합니다 ~

[sukangpunch]

저도 인성님 의견에 동의합니다!
POST /admin/auth/reissue 호출 할 때,
/admin 경로로 api 호출한다면 Security에 걸릴수 있으니(reissue 특성상 accessToken이 expired 된 상황에서 호출)
permit 만 잘 해주면 문제 없을 것 같습니다.