문제 상황

로컬

로컬 환경은 CORS처리가 이미 완료되어 있고, 프론트 3000포트와 백 5005 포트가 통신이 잘 된다. 언제나 그렇듯, 로컬 환경은 잘 되기 마련이다.
JWT + OAuth를 활용하여 인증 / 인가를 구현한 상황이었고, JWT 관련 토큰들은 "쿠키" 형태로 저장되고 있었다.

CloudFront

하지만 역시나 AWS 배포 후에는 문제가 터지고 말았다.
바로 "JWT 토큰이 쿠키로 발급되더라도, 새로 고침하면 해당 쿠키가 다 사라진다는 것이다."

문제점 분석

절차 (프론트엔드)

1. 웹 브라우저 개발자 도구를 연다.
2. 응용 프로그램 탭으로 이동한다.
3. 저장소 - 쿠키 탭으로 이동한다.

절차 (백엔드)

1. JWT 라이브러리 코드에 디버그 중단점을 건다.
2. 여러 가지 시나리오를 걸며 로컬에서 재현한다. (ex : api 호출 직전에 csrf token을 제거한다던지 등)

분석

삽질이 조금 걸렸지만, 생략하고 원인부터 바로 말하겠다.

쿠키의 도메인과 속성이 문제였다.

이걸 알게 된 건 다음 이유였다.

1. 로컬에선 백엔드에서 보낸 JWT 쿠키와 프론트엔드 브라우저에 담긴 도메인이 localhost로 모두 같다.
2. 클라우드 프론트에서 Google Analytics 쿠키는 살아 있는데, 백엔드에서 보낸 쿠키는 사라진다.

2.를 조금 더 자세히 설명하자면,
Google Analytics 쿠키의 도메인은 S3의 도메인인데, 백엔드의 도메인은 EC2 도메인 이름이였다.

해결

절차

1. 문제점 분석에서 보았듯이, 쿠키 도메인이 다른 것을 관찰하였다.
2. 쿠키 도메인 속성과 관련된 문제를 ChatGPT 4.0에게 질의하여 힌트를 얻었다.
3. 해당 문제 중, Cross-Domain Cookies 라는 것을 알게 되고, 해당 키워드로 구글에 검색했다.

결론

백엔드 (Flask)에서 SameSite = None, 쿠키 도메인을 프론트엔드 도메인(S3 도메인)으로 지정하였더니 해결되었다.

개발자 도구로 확인해보면, 백엔드에서 보낸 쿠키 도메인이 프론트엔드 도메인으로 바뀐 것을 확인할 수 있다.

그래도 안될 경우

여기까지 했는데, 안된다면 다시 개발자 도구를 살펴보자.
자세히는 모르지만, 클라우드 프론트는 쿠키 역시 캐싱을 하는 것 같다. 이 상태인 경우, "csrf double submit dose not match" 라는 에러가 발생한다.

이 때에는 백엔드 도메인으로 되어 있는 쿠키가 남아있는 것이므로, 해당 쿠키를 다 지우고 다시 실행해보라. 그러면 될 것이다.

느낀 점

플라스크 그만 쓰고 싶다. 프레임워크 자체가 너무 단순하다보니, 프로그램이 무거워질수록 개발하는 사람이 신경쓰거나 직접 구현해야 할게 많아진다.

플라스크는 프로토타입에나 쓰는 게 맞을 듯.

참고 링크

https://velog.io/@code-bebop/CORS%EC%9D%98-Cookie

https://velog.io/@ooooorobo/%EB%8B%A4%EB%A5%B8-%EB%8F%84%EB%A9%94%EC%9D%B8%EC%97%90-%EC%BF%A0%ED%82%A4-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0

https://blossoming-man.tistory.com/entry/https%EC%99%80-cross-domain%EC%97%90%EC%84%9C-%EC%84%9C%EB%B2%84%EC%99%80-%ED%86%B5%EC%8B%A0-%EC%8B%9C-%EC%BF%A0%ED%82%A4-%EB%B0%9B%EB%8A%94-%EB%B2%95