서버에서 클라이언트의 쿠키를 설정할 수 없었기에.

이번 프로젝트는 스프링 시큐리티 컨텍스트에서 스프링 oauth2-client를 통해서 로그인을 구현했다.

 

이전에는 oauth 과정을 직접 구현했던만큼, 이번 기회에 스프링에서 지원하는 라이브러리를 사용해서 oauth를 구현하고 싶었다.

 

즉, 서버에서 모든 oauth 과정이 이뤄지게 됐다.

---

 

서버에서 진행되는 oauth 인증을 시작하는 링크를 버튼으로 구현하여, 로그인은 성공적으로 이뤄질 수 있었다.

하지만, 이 상황에서 서버는 어떤 방법으로도 클라이언트의 쿠키값을 세팅할 수 없었다.

 

서버가 쿠키값을 세팅해야했던 이유는 oauth 인증 이후, 앞으로의 인가를 위한 jwt 의 엑세스 토큰을 저장하기 위함이다.

 

이를 해결하기 위한 노력(삽질)은 아래와 같다.

•  crossOrigin annotation
•  springSecurity - cors setting
•  webMvcConfigurer - cors setting
•  인증서(keyStore)를 통한 https 설정 (sameSite = None 설정을 위해서)
•  이외에도 여러 설정들을 교차하게 적용

모두 소용없었다. 물론 프론트측에서도 여러 경우에 따른 설정을 했다.

 

결론적으로 문제의 원인은 아래와 같다.

• 프론트와 백의 도메인이 다르다는 점

쿠키가 도메인에 매우 종속적임을 배웠다.

 

사실 변경된 oauth 과정의 문제일까 상당히 헤매기도 했는데, 그저 쿠키 <-> 도메인 의 문제인 것을 깨닫기까지 상당히 오래 걸렸다.

 

혹시 편법이 있지 않을까, 많은 자료들을 참고했지만 서버의 set-cookie는 실패했고,

어쩔수 없이 서버측에서는 redirect url에 엑세스토큰을 쿼리값에 포함시키려했다.

---

 

사실 엑세스 토큰의 claim에는 유저의 role과 idx 정도만 인코딩되어있고, 시크릿값을 유추해낼 수 없으니 괜찮지 않을까 싶었지만 마음에 들지 않았던 나는 다른 방법을 생각했다.

 

oauth 인증이 완료되고 프론트로 리디렉션할 때, 자바의 uuid 를 이용해서 난수를 만들어내고 그 값을 프론트에게 쿼리로 제공하는 것이다.

 

 

위 과정을 통해서 로그인이 완료된다면, 클라이언트측은 uuid 로 생성된 상태토큰(임시로 지은 이름)을 제공받고, 이를 통해서 엑세스 토큰 값을 요청한다.

 

상태토큰은 redis에서 관리되며, 이를 이용해서 엑세스 토큰을 발급하면 일회성으로 사라진다. (혹은 10초가 지나면 사라진다)

 

---

 

상당히 찝찝한 일이다. 근본적으로 해결하지 못해 회피할 수밖에 없는 상황이 발생했다는게.

 

배포시에 프론트와 백의 도메인을 같게 설정하는게 정도라고 생각한다.

 

오류 발생 지점을 미리 캡쳐해뒀다면, 더욱 실감났을텐데 아쉽다. 다음부턴 오류도 미리 정리해야겠다.