예전 백엔드 친구와 협업 개발 간에 보안상의 문제로 SameSite : none, secure = true, Http-only 다양한 설정을 하고 민감한 리프레시 토큰은 set Cookie를 사용하여 클라이언트에서 접근을 막고 액세스 토큰은 로컬스토리지에 저장하도록하여 구현하는 방법뿐이라고 생각했는데
맨날 백엔드 친구의 토큰을 헤더에 넣어 서버에서 클라이언트로 전달해 주는 것이다...라는 말의 의미를 api 반환값으로 생각했는데 쿠키 값은 클라이언트에서 접근 못하니깐 그 외의 반환 값인가라고 생각했다.
하지만 이번 개발 경험을 통해 이번 개발 경험을 통해 결국 쿠키에 들어간 값도 헤더 값인 것을 깨달았다.
HTTP 헤더(HTTP Header)는 클라이언트(예: 브라우저)와 서버가 HTTP 요청 또는 응답을 주고받을 때, 부가적인 정보를 전달하기 위해 사용되는 필드
요청 또는 응답에 대한 메타데이터 (요청 헤더, 응답 헤더)
그런데 이번 로그인 구현 과정에서 시간 상의 문제로 리프레시 토큰은 구현하지 않고 로그인을 하면 액세스 토큰을 반환받아서 클라이언트에서 직접 로컬스토리지에 액세스 토큰을 저장하는 방식을 사용했지만 구현하면서도 이 부분은 보안상으로 건강하지 않다고 생각했어서 그런지 백엔드 친구가 결국 액세스 토큰을 쿠키에 넣어서 다시 주겠다고 했다. 그러면 프론트 입장에서 할 일이 줄어서 편할 것이라고..(프론트가 뭐하는 것도 없는데 로컬 스토리지 작업을 통해 뭐한 척이라도 할려고 했지만 보안상의 문제는 항상 중요한 문제이긴 때문에 수용했다.)
그래서 액세스 토큰을 쿠키에 넣고 구현을 할려고하니?
그러면 인증처리는 어떻게 해야하지? 접근을 못하는데??
잘못된 방향과 생각이였다.
credentials: 'include'통해 쿠키값을 요청하면 해결이 된다.
결론
HttpOnly 쿠키에 저장된 JWT는 클라이언트 JavaScript에서는 접근할 수 없지만, 브라우저가 자동으로 요청 시 헤더에 쿠키를 담아주기 때문에 인증에 사용할 수 있다!
