-
Notifications
You must be signed in to change notification settings - Fork 3
Description
🐞 문제 상황 (Problem Description)
현재 카카오 회원가입 API는 닉네임과 인가 코드를 동시에 요구하고 있습니다.
그런데 카카오 정책상, 닉네임을 얻으려면 프론트엔드가 인가 코드를 먼저 사용해서 액세스 토큰을 발급받아야 합니다.
하지만 인가 코드는 일회성이라, 닉네임을 얻는 과정에서 이미 소진됩니다.
따라서 이미 사용된 인가 코드를 백엔드에 전달하면, 백엔드는 "잘못된 인가 코드"라며 요청을 거부하고 있습니다.
그래서 현재 API 명세로는 프론트엔드에서 닉네임과 유효한 인가 코드를 동시에 전달하는 것이 기술적으로 불가능한 것 같습니다.
💻 환경 정보 (Environment)
- 브라우저: Chrome 138
- 프론트엔드 프레임워크: React 19, Next.js
- 배포 환경: Vercel
- API 서버: 외부 REST API, 수정 불가
🔍 발생 원인 분석 (Investigation)
🛠 시도해본 해결 방법 (Attempts)
✅ 최종 해결 방법 (Final Solution)
제가 구현한 방식은 클라이언트가 카카오톡 프로필에 직접 접근해서 닉네임을 먼저 받아오는 방식은 아니고,
Next.js API 라우트를 BFF로 활용하는 구조입니다.
초기에는 다음과 같은 흐름을 고려했습니다:
프론트엔드에서 카카오 인가 코드를 받아 BFF로 전달하고
-> BFF에서 직접 카카오 API와 통신하여 인가 코드를 액세스 토큰으로 교환하고, 이 액세스 토큰으로 사용자 프로필(닉네임 포함)을 가져오고
-> 이렇게 가져온 카카오 액세스 토큰과 닉네임을 최종 백엔드 API 에 전달 하는 쪽으로 생각했었습니다.
그런데 스웨거를 확인해보니 백엔드에서 요구하는 token 값은 인가 코드였고, 동시에 nickname도 필수로 요구하고 있었습니다.
그래서 BFF에서 인가 코드를 백엔드로 그대로 넘기도록 구현을 변경했지만 아까 작성했듯, 인가코드가 일회성이라 닉네임을 얻으려면 액세스 토큰으로 교환해야 하고, 그 과정에서 인가 코드가 이미 소진된다는 모순에 부딪혔습니다.
결국, 인가 코드와 닉네임을 동시에 백엔드에 보내는 구조는 불가능하다고 판단했고, 이 방식은 잘못된 방향이라는 생각이 들었습니다.
제가 BFF를 도입한 주된 이유는 HttpOnly 쿠키로 토큰을 저장해 보안을 강화하려는 목적이 컸지만
카카오는redirect uri가 필수이고 이 URI가 인가 코드를 수신할 수 있는 서버여야 하기 때문에 자연스럽게 BFF가 이 역할을 하게끔 설계한것도 있습니다.
하지만 이 구조에서 BFF가 단순히 인가 코드를 백엔드로 넘기는 역할만 하게 되면
인가 코드가 클라이언트 → BFF → 백엔드로 전달되는 과정에서 네트워크 단계를 여러 번 거치면서 보안 위험이 증가하고,
백엔드에서 다시 카카오와 통신하려면 결국 카카오 회원가입, 로그인 로직이 중복되니까 복잡도가 늘어난다고 생각했습니다.
글로벌 노마드 백엔드가 애초에 토큰을 로컬스토리지 기반으로 관리하고, 쿠키 기반 설계는 염두에 두지 않았기 때문에 그런게 아닐까 하는 생각도 들었지만 카카오 회원가입, 로그인의 경우 redirect_uri가 필수로 사용되기 때문에, 현재 백엔드 구조는 설계적으로 개선 여지가 있는게 아닌가 싶었습니다.
제 이해가 맞는지, 혹시 제가 잘못 이해하고 있다면 추가 설명해주시면 감사하겠습니다! @과정 기획 담당_이용섭