[스프링부트] 쿠키를 이용하여 클라이언트와 통신 시 마주했던 에러들

현재 진행하고 있는 프로젝트에서 리프레시 토큰은 쿠키에, 액세스 토큰은 헤더에 담아서 통신을 하기로 했다. 얼마 전, 리프레시 토큰 구현을 마치고 로그인 시, 쿠키를 함께 반환하도록 기능을 구현했다. 그러나 이 과정에서 예상치 못한 오류들이 나왔다.

 

🍪 수정 전 쿠키 관련 세팅

private Cookie createCookie(TokenResponseDto tokenResponseDto) throws UnsupportedEncodingException {
        Cookie cookie = new Cookie(JwtTokenProvider.REFRESH_TOKEN_HEADER_STRING, tokenResponseDto.getRefreshToken());
        cookie.setMaxAge(Math.toIntExact(cookieValidTime));
        cookie.setHttpOnly(true);
        cookie.setPath("/");
        return cookie;
    }

response.addCookie(createCookie(tokenResponseDto)); // 쿠키 등록시

수정 전, 쿠키 관련 세팅은 위와 같았다.

key 는 RefreshToken, value 는 dto 에서 가져온 리프레시 토큰이었다.

setMaxAge 는 유효기간, setHttpOnly 는 보안상의 이유로 http 방식으로만 쿠키의 접근을 허용하는 것이다. setPath 는 쿠키가 적용될 url 의 path 를 지정한다.

 

🍭 HttpOnly 는 왜 필요할까?

쿠키는 클라이언트에서 조회되기 때문에 해커들은 이를 노린다. 따라서 Http 요청으로만 이에 접근할 수 있고, 브라우저에서는 이를 접근할 수 없도록 하는 것이다.

https://nsinc.tistory.com/121

[Web] HTTP Only와 Secure Cookie 이해하기

 

🍪 첫번째 오류 samesite

첫번째로 통신시 발생했던 오류는 samesite 였다. 이는 크롬 정책에 따른 오류로, 서로 다른 도메인에서 호출한 경우에는 브라우저에서 쿠키에 대한 설정을 막는다. 나의 프로젝트의 경우, 클라이언트와 서버의 도메인이 달랐기 때문에 이를 막은 것으로 보인다.

기본적으로 lax 로 되어있기 때문인데, 이를 None 으로 변경하면 해당 오류를 해결할 수 있다. 그러나 이 세팅을 위해서는 상단의 코드를 많이 바꿔야 했다.

https://kindloveit.tistory.com/100

[Spring boot] Chrome Cookie SameSite 해결하기

 

 private ResponseCookie createCookie(TokenResponseDto tokenResponseDto) throws UnsupportedEncodingException {
        return ResponseCookie.from(JwtTokenProvider.REFRESH_TOKEN_HEADER_STRING, tokenResponseDto.getRefreshToken())
                .path("/").sameSite("None").secure(true).maxAge(Math.toIntExact(cookieValidTime)).httpOnly(true)
                .build();}

response.addHeader("Set-Cookie", createCookie(tokenResponseDto).toString()); // 쿠키 등록

 

기존의 cookie 에는 samesite 관련 세팅을 할 수 없다. 따라서 스프링에서 제공하는 ResponseCookie 를 사용했다.

또한, 헤더에 등록하는 것이기에 string 으로 형변환을 하여 담아줬다.

 

🍭 ResponseCookie 는 무엇일까?

스프링에서 제공하는 쿠키이다. 이는 헤더의 set-cookie 에 원하는 속성을 추가할 수 있다.

 

🍪 두번째 오류 cors

cors 오류가 나지 않다가 쿠키를 적용하자 발생한다고 알려주셔서 cors 세팅을 다시 훑어봤다.

쿠키 + cors 키워드로 구글링을 하니 credentials 라는 답을 알게 되었다.

 

🍭 crendetials 는 무엇일까?

쿠키, 인증헤더, TLS client certificates(증명서) 를 의미한다. 이를 true 로 둔다는 것은 credentials 를 사용하겠다는 의미이다. 

 

🍭 cors의 crendetials 는 무엇일까?

기본적으로 호출은 쿠키가 없이 이루어진다. (credentials 가 false 로 되어있다.) 그러나, 클라이언트가 요청을 보내기 전에 withCredentials 가 true 로 되어 있지 않으면 다른 도메인에 대한 쿠키값의 설정이 불가능하다. 따라서 이를 true 로 두게 되면 클라이언트와 서버가 쿠키값을 공유할 수 있게 된다.

 

🍭 클라이언트는 요청을 두번 보내나?

관련 구글링을 하다가 options, preflighted 라는 단어들을 계속 마주치게 되어 찾아봤다.

 

🍭 preflighted 란?

브라우저의 요청이 안전한지 확인하기 위해서 브라우저가 본 요청을 보내기 전에 OPTIONS 메서드로 요청을 미리 한번 보내는 방식이라고 한다. 즉, preflighted 시에 withCredentials 가 true 가 아니었기에 cors 에러가 난 것임을 알 수 있었다.

 

https://wonit.tistory.com/571

[HTTP] OPTIONS 헤더와 Preflight 그리고 CORS

https://basemenks.tistory.com/246

Credentials 과 쿠키에 대해서

 

🍭 수정 이후 코드

 @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("https://localhost:3000", "클라이언트 서버", "클라이언트 서버")
                .allowedHeaders("*").allowedMethods("*").allowCredentials(true);
    }

기존에는 origins 에 * 로 해뒀었는데 credentials 를 허용하면 origins 를 직접 세팅해줘야 한다고 했고, 보안상 좋지도 않기에 수정했다. 

 

 

 

이렇게 수정해줬더니 통신에 성공~! Set-Cookie 가 잘 넘어오는 모습을 확인할 수 있었다.