발생 상황
프론트에게 토큰을 전달해주기 위해서 URL REDIRECT 형식으로 전달해주었다.
이를 바로 accessToken으로 사용하고 있는데,
이는 URL에 한번 노출된 토큰으로 보안에 굉장히 취약하다고 생각되었다.

해결 과정
1차 솔루션 - 노출된 토큰을 바로 accessToken으로 사용하지 않고 임시 accessToken을 통해 실제 accessToken을 받는다
FRONT_URL로
임시
accessToken을 담아 리다이렉트 시켜준다.{FRONT_URL}/login?token=${임시 access token}
이 ACCESS TOKEN의 유효시간을 매우 짧게 가져간 후, 해당 임시토큰을 통해 클라이언트가 로그인 요청을 하면
{ accessToken : ${실제 access token} userInfo : { // 로그인 된 user data } }
서버가 실제로 사용될 ACCESS-TOKEN을 유저 정보와 함께 보내준다
서버는 HTTPS 프로토콜을 사용하기 때문에 body에 담아서 주면
기존 방식(url에 모든 정보를 입력) 보안적으로 좀 더 개선 된 통신이 될 수 있을 것이라 예상된다.
- 하지만 애초에 임시라도 token을 url에 나오게 한 상황부터 보안적으로 위험할 수 있다고 판단되므로 좀 더 알아보아야 할 것 같다. 🤔
추가
URL에 토큰이 노출되는 문제를 해결하기 위해 헤더에 담아서 보내주는 것이 어떨까?
열심히 담아서 리다이렉트 해줬지만 결과는 원했던 타겟이 아닌 kakao?code= ..에
Authorization: Bearer …
이게 들어가 있다
원했던 목표는 그 다음에 나와있는 login?token=… 이곳이었는데, 그곳에는 내가 넣은 헤더가 없다 🥲
조금 더 고민해보아야 할 것 같다 ㅜㅜ
두 번째 문제가 발생했다.
우선 프론트에 토큰을 전달하는 과정을 리다이렉트 방식으로 해결하고자 했다.
하지만 리다이렉트를 하는 과정에서 요청지의 프론트 URL을 어떻게 알아내어야 할지가 문제가 되었다.
어떻게 하면 원하는 타겟에 내가 원하는 응답을 줄 수 있을까? 🤔
현재 프론트는 localhost:3000에서 개발하고 있고,
프론트 배포서버는
checkmoi.vercel.app
를 사용하고 있다.이 두 서버를 동적으로 리다이렉트를 시키기 위해서는 최초 요청지를 알아야 한다고 생각되었다.
최초 요청지를 찾아보자..

- Using the HTTP Referer header
- HTTP Referer 을 확인했으나 원하는 프론트의 URL이 발견되지 않았다.
- 카카오가 referer..

- Saving the original request in the session
- 우리는 현재 세션을 사용하지 않고 토큰방식을 쓰고 있는데 이걸 사용할 수 있나?
- 만약 된다고 하더라도 이걸 사용한다면 토큰을 사용할 이유가 없지 않을까..? 🤯
- 어떻게하징..
추가 3
프론트의 요청을 동적으로 알아내어 리다이렉트를 하는 것에 문제를 겪고 있었다.
우선, 왜 동적으로 알아내려고 했을까?
리다이렉트로 임시 토큰을 발행하는 과정에서 프론트와 백엔드가 계속 개발하고 배포하는 환경에 한가지 URL로만 리다이렉트 된다면, 로컬에서는 되고 서버에서는 안되는 상황이 발생한다. 이를 피하고 어느 환경에서든 지속적으로 개발하고 배포하여 바로바로 확인할 수 있도록 안정적으로 하는것이
동적으로 URL을 알아내어야 하는 이유라고 생각했다.
현재 진행상황은 다음과 같다.
나는 프론트의 요청지를 사전에 미리 알고 있으므로 이 정보를 이용해 해당 문제를 해결해보자.
프론트의 요청을 판단하는 부분을 프로파일을 통해서 다음과 같이 바라보도록 했다.
개발 서버 : dev →
localhost:3000
상용 서버 : prod →
checkmoi.vercel
프론트는 다음을 바라보도록 했다
개발 서버 : localhost:3000 → dev.checkmoi.ga
상용 서버 : checkmoi.vercel → checkmoi.ga
이렇게 한다면 dev서버의 변경사항을 프롱님들이 로컬에서 빠르게 받아서 활용할 수 있다.
배포된 프론트 페이지 또한 운영서버를 바라봄으로써 정상적으로 작동할 수 있을 것으로 기대된다.