Token 관련 정보를 Cookie 로? 아니면 Payload 로?

[Sunja-An]

Token 관련 정보를 Cookie 로? 아니면 Payload 로?

최근 보안관련 이슈가 증가하고 있는 추세에서, 인증/인가 부분에 대한 고민이 생겨 프론트분들께 여쭤보고 싶은게 생겼습니다!

[Main Point]

인증/인가 관련해서 서버측에서 정보를 전달할 때, Cookie 로 RefreshToken 를 전달할 지 아니면 Payload 로 전달할지에 대해 의견을 여쭤보고 싶습니다.

개요

Reddit 을 살펴보던 중, 많은 사람들이 WAS ( Server ) 에서 httpOnly 설정을 추가하고, Domain 을 서버 쪽 Domain 으로 설정해놓은 Cookie 를 발행하고 있는 것을 알 수 있었습니다. 해당 방식처럼 사용했을 때, React 에서 LocalStorage 를 이용하지 않고, 자동으로 AccessToken 과 RefreshToken 에 대해서 보낼 수 있다는 장점이 있어, Response 에 Server 측에서 쿠키를 구워서 전달해주는 방식을 생각하고 있습니다! 🍪 ( 현재는 Payload 로 전달하고 있습니다! )

논의하고 싶은 부분

하지만 제가 알기로는 Server 에서 Cookie 를 구워서 전달할 경우, Domain 이 달라 React.js ( CSR관점 ) 에서 Third-party 쿠키로 간주하는 문제가 발생하는 걸로 알고 있습니다.
그리고 이번 프로젝트에서 Next.js 를 사용하는 걸로 알고있는데, Next.js 에 대해서는 큰 지식을 가지고 있지 않아서, Cookie 관련 부분에서 어떤 사용방식을 가져가는지에 대해 프론트엔드분들은 어떻게 생각하시는지 궁금합니다!

[eunwoo-levi]

Next.js를 BFF(Route Handler)로 쓰는 현재 구조 기준으로 보면,
저는

백엔드 → BFF(Next Route Handler) 구간은 JSON payload로 토큰 전달
BFF → 브라우저 구간은 HttpOnly 쿠키로 토큰 관리

이 조합이 가장 자연스럽다고 생각합니다.

지금은 브라우저가 직접 백엔드에 붙는 React SPA 구조가 아니라,

Browser  <->  Next.js Route Handlers (/api/**)  <->  Spring Backend

이렇게 항상 Next.js를 한 번 거치기 때문에,
백엔드에서 Set-Cookie를 내려도 그 응답을 먼저 받는 쪽은 브라우저가 아니라 Next.js 서버입니다.
그래서 “백엔드가 쿠키를 굽고, 브라우저는 자동으로 쿠키를 들고 다닌다”는 전형적인 SPA 패턴이 그대로 성립하지 않습니다.

반대로, 백엔드는 BFF에게

{ "accessToken": "...", "refreshToken": "..." }

처럼 payload로만 응답을 주고,

이 값은 서버-서버 통신(백엔드 ↔ Next.js) 에서만 보이고 Next.js Route Handler가 이 값을 읽어서 Set-Cookie(HttpOnly + Secure + SameSite 옵션)를 직접 구성해 브라우저에 내려주면

브라우저 입장에서는 오직 HttpOnly 쿠키만 가지고 움직이게 됩니다.
클라이언트 JS 코드에서는 토큰을 읽을 수 없기 때문에 XSS로 인한 토큰 탈취 위험도 줄이고,
도메인 분리로 인한 3rd-party 쿠키/ITP 이슈도 피할 수 있습니다.

정리하면, 우리처럼 Next.js BFF가 사이에 있는 구조에서는 (여기서 말하는 BFF는 Next.js Server(Route handler)를 뜻함)

• 백엔드가 직접 브라우저 쿠키를 책임지는 것보다
• 백엔드 ↔ BFF는 payload, BFF ↔ 브라우저는 HttpOnly 쿠키로 역할을 나누는 게
  • 토큰 노출 범위도 줄이고
  • 도메인/쿠키 정책도 BFF 한 곳에서 일관되게 관리할 수 있어서 더 맞는 방향이라고 생각합니다.

[Sunja-An]

섹시한 답변 감사합니다 😭
책임 나누는 부분에서 크나큰 공감을 했네요,,

+) 현재 방식이 Access, Refresh Token 정보를 전달하는 방식이여서, 현행 유지해놓도록 하겠습니다!

[polyglot-k]

@eunwoo-levi
그냥 단순히 질문이긴 한데 Next 에서 서버 레벨에서 뭔가를 처리하고 하는게, 큰 부하는 없나요? ☺️☺️
기술 블로그에서도 이런 구조를 많이 봤는데, 사용자가 많았을 때 Next 서버 측에서도 scale-out 과 같은 조치가 가능한 구조인지 궁금합니다!

[polyglot-k]

확실히 테스트 자체는 Next 서버 측에 있는 형태라면 이전에 MOSU 프로젝트에 비해서 실험해보는건 탄력적으로 좋을 것 같은데, 다른 사이드 이펙트는 없을지 답변 남겨주시면 감사하겠습니다!

[eunwoo-levi]

@polyglot-k
좋은 질문 감사합니다:)

일단 저의 생각에 대한 결론을 말씀드리자면, 지금처럼 Next.js를 BFF(Route Handler)로 두고 Token 처리 및 Proxy 정도를 서버 레벨에서 하는 건 부하 관점에서 크게 부담되는 패턴은 아니고, 트래픽이 늘어났을 때도 일반 웹 서버처럼 충분히 scale-out 가능한 구조라고 생각합니다!

• BFF에서 하는 일 자체가 가볍습니다.
  Route Handler에서 하는 건

  • 쿠키 읽기/설정
  • accessToken 만료 시 /auth/refresh 한 번 호출
  • 백엔드로 요청을 프록시하고 응답을 살짝 가공해서 내려주는 정도라
    CPU-heavy 연산이 아니라 대부분 I/O(bound) 작업이라 Next 서버에 큰 계산 부하를 주는 역할은 아닙니다.
    비즈니스 로직, DB 쿼리, 무거운 연산은 그대로 Spring 쪽에 남겨두고, Next는 얇은 BFF 레이어로 유지하려고 하고 있습니다.

• Next.js 서버도 일반 서버처럼 수평 확장이 가능합니다.
  Next는 결국 Node.js 서버라서,

  • 컨테이너(ECS, K8s 등)로 올리면 인스턴스 수를 늘려서 scale-out 할 수 있고,
  • Vercel / 서버리스(Lambda) 같은 환경에서는 플랫폼 차원에서 함수 인스턴스를 자동으로 늘려주기 때문에
    BFF가 특별히 “스케일 불가능한 특수한 서버”는 아닙니다.
    오히려 인증·도메인·쿠키 정책을 Next 레이어에 모아두면, 확장할 때도 한 종류의 서버만 신경 쓰면 돼서 운영이 더 단순해지는 장점이 있다고 생각합니다.

• 트래픽 증가 시 병목이 되지 않게 설계할 수 있습니다.

  • BFF는 state를 많이 들고 있지 않아서 stateless하게 두기 쉽고,
  • 필요하다면 특정 API에 캐싱을 붙이거나(예: 공통 설정, 정적 데이터),
  • Rate limiting도 BFF 레벨에서 걸어줄 수 있어서 오히려 백엔드 보호용 “완충 레이어”로 쓰기에 좋은 위치라고 보고 있습니다!

언제든지 궁금하신 내용이 있으시면 편하게 질문주시면 감사하겠습니다 😄

[toothlessdev]

@eunwoo-levi
은우님이 말씀해주신것처럼 WAS (Spring) 에서 access, refresh 토큰을 발급받아 BFF (Next) 로 응답을 주고, BFF 에서 브라우저로 쿠키를생성하여주는 방식을 채택했을때,

추후에 인증이 필요한 api 를 요청할때는 흐름이 어떤식으로 이루어지는건가요 ?

브라우저 쿠키 (access, refresh) 를 BFF (Next) 로 전달하면 해당 쿠키에 있는 토큰을 WAS (Spring) 의 Header Authorization 필드로 미들웨어단에서 처리하는건가요 ?

그렇다고 했을때 서버컴포넌트가 아닌 브라우저에서 다이렉트로 WAS (Spring) 으로 요청을 하는경우에는 WAS 가 Authorization 필드가 아닌 쿠키를 받기때문에 로직이 복잡해지거나 제대로 토큰을 받지 못할것 같은데 어떤식으로 처리하는지 궁금합니다!

[eunwoo-levi]

@toothlessdev
좋은 질문해주셔서 감사합니다:)
해당 방식에는 여러 방법이 있겠지만 제가 주로 구현한 방법을 중심으로 설명하겠습니다!

제가 의도한 구조는 “브라우저는 항상 BFF(Next)만 호출하고, WAS(Spring)는 내부용 API 서버로만 쓴다”가 전제입니다.

인증이 필요한 API 호출 흐름을 보자면,
WAS(Spring)에서 access/refresh 토큰을 발급해서 BFF(Next)로 내려보내고,
BFF가 브라우저 기준으로 HttpOnly + secure + sameSite=strict 쿠키를 세팅한 뒤에는 흐름이 아래와 같이 갑니다.

1. 브라우저 → BFF 요청
   • 예: GET /api/profile
   • 이때 브라우저는 자동으로 accessToken, refreshToken 쿠키를 BFF 도메인으로 같이 보냅니다.
2. BFF(Next)에서 쿠키 → Authorization 헤더로 변환
   • Route Handler에서 cookies()로 토큰을 읽고,
   • 필요하면 /auth/refresh로 새 accessToken을 받아서 쿠키 갱신한 뒤,
   • 최종적으로 아래와 같이 호출합니다.

     GET /user/profile
     Authorization: Bearer {accessToken}
     

위 내용이 질문 주신 “미들웨어 단에서 처리하나요?" 에 대한 답변에 도움이 되었으면 좋겠습니다!

3. WAS(Spring)는 오직 Authorization 헤더만 신뢰
   • Spring 쪽은 “항상 헤더에 실린 Bearer 토큰”만 보고 인증을 판단하고, 쿠키는 신경 쓰지 않습니다.
   • 브라우저 쿠키 → 헤더로 옮겨주는 역할은 전부 BFF가 맡고 있습니다!

---

추가적으로 말씀해주신 것처럼,
만약 브라우저에서 Spring으로 직접 요청을 날리면 Spring은 쿠키만 받고 Authorization 헤더는 못 받는 상황이 될 수 있는데,

이 구조에서는 그 시나리오 자체를 허용하지 않는 게 전제입니다.

• Spring 서버는 내부망 / 별도 도메인으로 숨기고,
• CORS, 네트워크 라우팅 등으로 브라우저 → Spring 직통 호출을 막고,
• 브라우저는 항상 https://myapp.com/api/** (BFF)만 바라보도록 설계합니다.

즉,

• 브라우저 ↔ BFF(Next): 쿠키 기반 (HttpOnly, 자동 전송)
• BFF(Next) ↔ WAS(Spring): Authorization: Bearer ... 기반

이렇게 경계를 명확히 나누는 게 핵심이라,
Spring 입장에서는 “내가 직접 쿠키를 받을 일은 없고, 항상 BFF가 Bearer 토큰을 붙여준다”라고 가정하고 구현하게 됩니다.

말이 좀 장황해진 것 같지만, 답변에 도움이 되셨으면 좋겠습니다 😄