전체 글

refreshToken 저장위치와 형태 고민

RefreshToken의 저장 위치(LocalStorage vs Cookie) LocalStorage - 장점: 편리성 - 단점: XSS 취약 쿠키 (httpOnly + secure) - 장점: XSS에 다소 강함(httpOnly + secure) - 단점: CSRF에 취약 결정 hyper-link(통합플랫폼)에서는 refreshToken을 쿠키에 저장하기로 결정했다. 왜냐하면 httpOnly와 secure 옵션을 주면 XSS에 LocalStorage보다 상대적으로 덜 취약하기 때문이다. 물론 쿠키는 CSRF에 취약하다는 단점이 존재한다. 하지만 우리가 저장하는 것은 refreshToken이다. CSRF 공격이 오더라도, refreshToken만을 가지고는 비지니스 데이터에 영향을 줄 수 없다. 왜냐하..

인증 방식 고민(SlidingSession VS RefreshToken)

AccessToken만 사용 짧은 만료 시간: 장점: 토큰 탈취당해도 빠르게 만료 가능 단점: 사용자가 자주 로그인 해야함(불편함) 긴 만료 시간: 장점: 사용자가 로그인 자주할필요X(편함) 단점: 토큰 탈취시 오랫동안 제약없이 사용 Sliding Sessions + AccessToken AccessToken을 가진 클라이언트의 요청에 대해 서버가 새로운 AccessToken을 발급해주는 방법 (요청때마다 새롭게 AccessToken 발급) 장점: 로그인을 자주 할 필요 X 글을 작성, 결제 등 세션 유지가 필요한 순간에 세션 만료 문제를 방지 단점: 접속이 주로 단발성으로 이루어지는 서비스의 경우효과가 크지 않음 긴 만료 시간을 갖는 AccessToken 사용하는 경우, 로그인을 전혀 하지 않아도 되는..

cookie 미적용 문제(same-site)

refreshtoken을 쿠키에 저장하기로 결정했다. 구현 후 프론트와 연동을 진행하는데, 쿠키가 적용되지 않았다. 개발자 도구에서 응답 메시지를 보니 set-cookie는 잘 동작했다. 하지만 왜 브라우저에서는 저장이 되지 않는 걸까? 찾아보니 원인은 same-site 정책 때문이었다. cookie에서도 cors처럼 Origin이 다를 경우에 각 브라우저마다 정해놓은 보안정책이 존재했다. 구글 크롬에서는 same-site 정책을 none으로 설정할 경우 secure가 true인 경우만 쿠키 저장이 가능했다.(https) (확인해보니 사파리에서도 동일하다) 이제 개념적으로 좀 더 알아보자. Third-party 쿠키와 First-party 쿠키 서드 파티 쿠키: 사용자가 접속한 페이지와 다른 도메인으로 ..