
협력 시에 생기는 문제는 뭔가 또 새롭다. 서로 다른 영역을 최대한 이해하면서 진행하기 때문에 머리아프지만서도 이게 협업 프로젝트구나 싶고.
프로젝트에서 인증토큰을 넘겨주는 방식은 아래와 같다.
- 토큰 발급
- access는 response body
- refresh는 쿠키로 보냄
- 프론트가 access는 로컬 스토리지에 저장하고 인증 요구 api에 헤더에 넣어서 보냄, refresh는 터치 x
백엔드 서버에서 리프레시를 쿠키에 넣고 알아서 그 값을 필요할 때 읽어오도록 설정했기 때문에 프론트에서는 터치할 이유가 없다.
근데 문제는 로그아웃 때 자꾸만 UnAuthorized 에러가 발생하더라.
로그아웃 시, 쿠키에 기존 리프레시가 있는지 확인한다. 그리고 나서 존재하는 리프레시를 지우게 되는데, 존재하지 않는다면 UnAuthorized 에러가 발생하게 되는 것이다. 근데 분명 스웨거에서는 쿠키 내 리프레시가 있는것을 확인도 했고 로직에도 문제가 없었다. 프론트 로컬에서 시도를 하면 생기는 문제였다.
에러가 다행히 발생하는 경우는 위에서 얘기했던 것 처럼 "쿠키 내에 리프레시가 없는 경우"밖에 없었다. 그러면 프론트 로컬 서버에서 생기는 문제라는 건데, 프론트 로직 자체에는 문제가 없었으며 또 다시 확인 되는 문제는 프론트 측에서 이 쿠키에 대한 관여가 전혀 되지 않는 다는 것이었다.
다같이 의논해본 결과 백에서 보내는 쿠키의 설정에서 다른 환경에서 관여가 안되도록 설정이 되어있는 것 같다고 추측했다. 그 중에 "sameSite"설정이 가장 의심스러웠기 때문에 서버에서 보내는 sameSite설정을 none으로 바꿔주기로 했다.
@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
//...생략
@Bean
public CookieSameSiteSupplier applicationCookieSameSiteSupplier() {
return CookieSameSiteSupplier.ofNone();
}
}
위 설정은 백에서 보내는 쿠키를 전역으로 sameSite = none 처리해주는 것이다.
다행히 위 설정으로 해결. 이유는 samesite 설정이 default가 lax이기 때문에 발생한 문제였다.
- None: SameSite 가 탄생하기 전 쿠키와 동작하는 방식이 같습니다. None으로 설정된 쿠키의 경우 크로스 사이트 요청의 경우에도 항상 전송됩니다. 즉, 서드 파티 쿠키도 전송됩니다. 따라서, 보안적으로도 SameSite 적용을 하지 않은 쿠키와 마찬가지로 문제가 있는 방식입니다.
- Strict: 가장 보수적인 정책입니다. Strict로 설정된 쿠키는 크로스 사이트 요청에는 항상 전송되지 않습니다. 즉, 서드 파티 쿠키는 전송되지 않고, 퍼스트 파티 쿠키만 전송됩니다.
- Lax: Strict에 비해 상대적으로 느슨한 정책입니다. Lax로 설정된 경우, 대체로 서드 파티 쿠키는 전송되지 않지만, 몇 가지 예외적인 요청에는 전송됩니다.
(앞 내용 중략)
또한 "안전하지 않은" POST나 DELETE 같은 요청의 경우, Lax 쿠키는 전송되지 않습니다. 하지만 GET처럼 서버의 서버의 상태를 바꾸지 않을 거라고 기대되는 요청에는 Lax 쿠키가 전송됩니다.
Secure 필수 정책
SameSite 속성으로 None을 사용하려면 반드시 해당 쿠키는 Secure 쿠키여야 합니다. Secure 쿠키는 HTTPS가 적용된(그러니까 암호화된) 요청에만 전송되는 쿠키입니다. 이 정책을 구현하는 브라우저도 현재로서는 크롬밖에 없습니다. 그래서 크롬에서는 SameSite=None으로 Set-Cookie를 사용하면 다음과 같이 쿠키 자체가 제대로 설정되지 않습니다.
reference : 브라우저 쿠키와 SameSite 속성
원래 캡처해서 보여주고 싶었는데 그날 새벽에 겨우 수정하고 자버려서 생생한 에러의 흔적은 온데간데 없다..(아쉽)