"다시 한다면 어떻게 할까" — 인증 아키텍처 회고와 개선안

4-1. Path 제한 — “이 쿠키, 어디까지 따라가게 할 거야?”

쿠키의 Path 속성은 이 쿠키가 어떤 URL 경로의 요청에 자동 첨부될지를 정합니다. Path=/로 두면 같은 도메인의 모든 경로에서 자동 전송됩니다.

지금 설정(Path=/)에서 실제로 어떻게 동작하는지 보면:

1
브라우저 쿠키 저장소:
2
  refresh_token (Path=/, HttpOnly, Secure, SameSite=Lax)
3

4
→ GET /api/users          : 쿠키 자동 첨부 ✗ 사실은 필요 없음
5
→ POST /api/orders        : 쿠키 자동 첨부 ✗ 사실은 필요 없음
6
→ GET /dashboard          : 쿠키 자동 첨부 ✗ 사실은 필요 없음
7
→ POST /api/auth/refresh  : 쿠키 자동 첨부 ✓ 진짜로 필요
8
→ POST /api/auth/logout   : 쿠키 자동 첨부 ✓ 진짜로 필요

전송된다고 해서 백엔드가 그 값을 쓰는 건 아니지만, HTTP 요청 헤더에 토큰이 매번 같이 흐른다는 것 자체가 노출 면적입니다. 로깅 설정이 잘못된 미들웨어, 디버깅용 프록시, APM 도구 등에서 우연히 쿠키 값이 평문으로 캡처될 수 있습니다.

Path=/api/auth로 좁히면 이렇게 바뀝니다:

1
브라우저 쿠키 저장소:
2
  refresh_token (Path=/api/auth, HttpOnly, Secure, SameSite=Lax)
3

4
→ GET /api/users          : 쿠키 미전송 (Path 매치 안 함)
5
→ POST /api/orders        : 쿠키 미전송
6
→ GET /dashboard          : 쿠키 미전송
7
→ POST /api/auth/refresh  : 쿠키 전송 ✓
8
→ POST /api/auth/logout   : 쿠키 전송 ✓

부가 효과:

• 일반 API 호출 30여 개에 쿠키가 아예 첨부되지 않음 → 사고로 새는 면적 축소
• 2편의 SameSite Lax 빈틈 중 “GET 통과” 시나리오의 공격 표면도 같이 줄어듦 (외부 사이트가 <a href="https://example.com/api/something">을 만들어도 그 경로엔 쿠키가 안 가니까)
• 백엔드의 일반 API 미들웨어가 실수로 req.cookies.refresh_token을 참조해도 그냥 undefined라 사고 차단

4-2. __Host- prefix — 이름만 바꿔도 브라우저가 안전장치를 강제한다

Set-Cookie 헤더에서 쿠키 이름이 __Host-로 시작하면, 브라우저는 그 쿠키를 받기 전에 다음 세 가지가 모두 만족되는지 검사합니다. 하나라도 어긋나면 쿠키 자체를 거부합니다.

이름만 refresh_token → __Host-refresh_token으로 바꾸는 거라 코드 변경량은 작지만, 보호 효과는 큽니다. 특히 세 번째 조건이 핵심입니다.

1
admin.example.com : 사용자가 로그인된 관리자 도구
2
blog.example.com  : 마케팅 팀이 운영하는 워드프레스 (XSS 사고 빈번)
3

4
[기존: Domain=.example.com인 쿠키]
5
blog 측 XSS 스크립트가 fetch('https://admin.example.com/api/auth/refresh') 호출
6
→ 브라우저: "같은 example.com이니까" 쿠키 자동 첨부
7
→ admin 측 토큰이 갱신되어 공격자가 새 accessToken 획득
8

9
[__Host-refresh_token으로 바꾸면]
10
Domain 속성 자체가 금지되어 쿠키는 admin.example.com에만 묶임
11
→ blog 측에서 같은 fetch를 호출해도 쿠키 미첨부
12
→ 공격 차단

4-3. 그래서 다시 한다면 무엇을 고를까

위 두 가지는 양자택일입니다 (__Host-는 Path=/를 강제하니까). 무엇을 막을지에 따라 선택이 갈립니다:

이 프로젝트는 단일 도메인이라 다시 한다면 후자(Path=/api/auth)로 갔을 겁니다. 다만 향후 admin.*, analytics.* 같은 서브도메인 확장 가능성이 보이면 그 시점에 __Host-로 전환을 검토하는 식으로요.

5-1. 최소 로깅 — 어떤 프로젝트든 기본

• 로그인 성공/실패 이벤트
• 401 응답 카운트
• 자동 refresh 시도·실패율 (프론트 측 Sentry 등)

이 정도는 프레임워크 기본 로그 + Sentry 같은 도구를 깔면 거의 따라오는 비용입니다. 이 프로젝트도 1일차부터 잡았어야 했고, “도입”이라 부르기도 애매한 수준입니다.

5-2. 상세 로깅 — 사고 났을 때 피해가 큰 서비스에서만

• 사용자별 refresh 호출 빈도 (rolling window)
• 동일 사용자 토큰의 IP / UA 변화
• 로그인 실패 패턴 (브루트포스 탐지의 기반)

이건 다릅니다. 로그를 어디에 쌓을지, 어떻게 모아 볼지, 어느 수치를 넘으면 알람을 띄울지까지 다 정해야 하는 작업이고, 실제로 공격당할 가능성이 있는 서비스에서만 들인 만큼의 효과가 나옵니다 — 금융·헬스케어·결제, 또는 외부에 공개된 사용자 많은 서비스. 수십 명짜리 B2B 내부 도구에는 과투자입니다.

이런 항목들은 대부분 백엔드에서 남겨야 하는 데이터라 프론트 혼자 결정할 수 있는 영역도 아닙니다. 다시 한다면 도메인이 “상세 로깅이 필요한 쪽”이라고 판단된 시점에 백엔드 팀에 이 스키마를 함께 잡자고 발의하겠습니다. 그래야 “비정상 패턴은 무엇인지”를 정의할 수 있고, 그 위에 rate limit이나 강제 로그아웃 같은 차단 정책을 얹을 수 있습니다. 데이터 없이 감으로 임계값을 잡고 차단하면 정상 사용자만 막히는 함정에 빠집니다.

지금 Middleware가 못 하는 것

현재 Next.js Middleware는 보호 라우트 진입 시 쿠키 존재 여부만 확인합니다.

1
// 지금 구조
2
export function middleware(req) {
3
  const hasRefresh = req.cookies.get('refresh_token')
4
  if (!hasRefresh) return NextResponse.redirect('/login')
5
  return NextResponse.next()
6
}

이게 못 하는 일들:

• 유효성 검증 — 쿠키가 있긴 한데 만료된 거면? 일단 통과시킨 뒤 클라이언트가 refresh를 호출해서야 알 수 있음
• 권한 분기 — /admin/* 라우트인데 일반 사용자면? Middleware는 모르고, 페이지 컴포넌트가 렌더링된 뒤 클라이언트가 백엔드에 별도 호출해야 함
• 사용자 식별 — 라우트별 redirect, A/B 분기, 로깅에 userId가 필요해도 Middleware는 모름

해결하려면 Middleware에서 백엔드에 매번 검증 요청을 보내야 하는데, 그러면 모든 페이지 진입에 백엔드 round-trip이 추가됩니다. 그래서 결국 안 했고, 그 만큼 책임이 페이지/컴포넌트 단으로 흘러 들어갔습니다.

JWT를 쓰면 무엇이 가능해지는가

accessToken을 JWT로 발급하면 Middleware가 백엔드 없이 토큰을 검증할 수 있습니다:

1
// JWT 도입 시 가능해지는 구조 (개략)
2
export async function middleware(req) {
3
  const token = req.cookies.get('access_token')?.value
4
  if (!token) return redirectTo('/login')
5

6
  const payload = await verifyJWT(token, PUBLIC_KEY)  // 서명 검증 + 만료 확인
7
  if (!payload) return redirectTo('/login')
8

9
  // payload.role, payload.userId 등을 즉시 활용
10
  if (req.nextUrl.pathname.startsWith('/admin') && payload.role !== 'admin') {
11
    return redirectTo('/forbidden')
12
  }
13
  return NextResponse.next()
14
}

얻는 것:

• 페이지 진입 단계에서 권한·만료 검증이 끝남 → 컴포넌트가 깨끗해짐
• 백엔드 round-trip 0회 → edge에서 처리되어 응답이 빠름
• payload.userId를 헤더로 백엔드에 전달하면 백엔드도 토큰 디코딩을 한 번 덜 할 수 있음

이게 정말 매력적이라, 만약 라우트별 권한 분기·SSR 개인화·B2B의 멀티 테넌시 같은 요구가 1일차부터 있는 프로젝트였다면 처음부터 JWT를 진지하게 검토했을 겁니다.

그런데 1편의 결정 근거는 아직 유효한가

JWT의 가장 큰 약점, 즉시 무효화 어려움은 그대로입니다. accessToken을 짧게(예: 15분) 두고 Refresh Token Rotation(위 3번)으로 보완하는 게 정석이지만, 이건 다음 두 가지를 받아들이는 결정이기도 합니다:

그래서 다시 한다면

“JWT로 바꾼다”가 아니라 “JWT + Middleware 조합을 1주일 정도 시간 들여 진지하게 평가한다” 가 결론입니다. 평가 기준은:

• /admin, /user/profile 같은 페이지마다 인가(누가 이 페이지를 볼 수 있는지 권한 체크) 코드가 각 페이지 안에 흩어져 있는가 (그렇다면 Middleware 한 곳에서 처리하는 게 훨씬 깔끔)
• 서버에서 HTML을 미리 만들어 보낼 때 “이 사용자가 누구인지”를 그 시점에 알아야 하는 화면이 있는가 (예: “안녕하세요 ○○님” 같은 개인화, 사용자 그룹별로 다른 UI 보여주기, 누가 이 페이지에 들어왔는지 서버에서 기록)
• 사용자가 로그아웃을 눌렀거나 관리자가 계정을 정지시켰을 때, 그 즉시 차단되지 않고 최대 15분까지 그대로 살아있는 상황을 받아들일 수 있는 서비스인가 (JWT는 토큰 자체가 만료될 때까지 유효해서, accessToken을 15분짜리로 두면 그 동안은 무효화가 안 됨. 금융·헬스케어처럼 1초라도 늦으면 안 되는 도메인은 부적합)
• 비밀 키를 안전하게 보관·교체·배포할 인프라(AWS KMS 등)가 이미 있거나, 새로 도입할 의향이 있는가

체크박스가 두 개 이상 켜지면 JWT를 도입하느라 드는 비용(키 관리·15분 지연 감수 등) 대비 얻는 이득이 보입니다. 모두 꺼지면 지금 구조(세션 토큰 + HttpOnly 쿠키)가 여전히 정답입니다.