조급하면 모래성이 될뿐

결론 - accessToken, refreshToken 모두 httpOnly 쿠키로 응답했다. (XSS 공격 방지) - 하지만 refreshToken을 통한 재발급 로직을 구현하기 위해서 httpOnly옵션의 accessToken 쿠키는 서버에서 추가적으로 신경 써주어야 한다. (FE팀에서 조차 accessToken에 접근할 수 없기 때문에 토큰 만료시점을 알 수 없다..) 장점 - XSS 공격 방지할 수 있음. 단점 - 쿠키 관리신경 써야 함 - 서버 로직이 복잡해질 수 있음 (비교적..) 직면한 문제 1 accessToken 쿠키 만료시간. 처음에는 accessToken 쿠키 만료시간을 JWT와 동일하게 주었다. 프론트에서는 토큰 만료 여부를 서버응답에 의존하기 때문에 쿠키가 사라지게 되면 서버에서는..

현재 진행하는 프로젝트에서는 소셜로그인을 사용하지 않는다. 자체 인증시스템이 필요했고 JWT를 적용했다. 기존의 인증방식 기존의 쿠키나 세션방식은 서버 또는 클라이언트에 유저 정보를 저장하여 인증을 수행한다. 쿠키는 웹 브라우저에 저장하기 때문에 비교적 쉽게 탈취당할 수 있다. 세션은 다중서버구현 시 정합성을 보장할 수 없다. A클라이언트의 요청을 S1서버에서 인증했을 때, 두 번째 요청이 S2로 전송되면 S2세션에는 A유저의 정보를 모르기 때문에 인증이 되지 않는다. (스티키 세션, 세션 클러스터링, 메모리 디비를 사용해 해결할 순 있다.) JWT JWT는 RFC 7519 버전에 만들어진 약속이다. JWT의 핵심은 서명된 토큰이라는 것이다. 쉽게 서버에서 지정한 SecretKey로 JWT토큰을 만들어서..