청소 플랫폼 만들기 (20)
└ 엑세스/리프레시 토큰
이전 TIL 내용 수정공부하며 느낀 점
참조한 페이지
내가 구현한 로그인 기능의 보안에대해 지적받은게 많아서 엑세스/리프레시 토큰에 대해서 다시 공부해봤다.
엑세스 토큰 : 우리가 보통 로그인할 때 만드는 JWT이다.
이 브라우저가 해당 id에 대해 인증을 완료했으며, 만료 될 때까지 서버에 엑세스 할 수 있다는 것을 증명한다.
문제는 엑세스 토큰은 서버가 아닌 클라이언트에 저장되고, 무상태 ( statless ) 라는 웹의 특성상, 탈취 될 경우 토큰의 유효기간동안 해커가 클라이언트를 사칭할 수 있다는 것이다.
그래서 나온 것이 리프레시 토큰이다.
엑세스 토큰과 똑같은 JWT이다. 로그인 성공시 서버(DB)와 클라이언트(쿠키) 양쪽에 저장을 한다.
엑세스 토큰의 유효기간은 짧게 설정하고, 엑세스 토큰이 만료되면 리프레시 토큰을 비교하여 일치할시 엑세스 토큰을 재발급한다.
엑세스 토큰이 만료된 경우
+
사용자가 로그아웃을 한 경우 : 리프레시 토큰이 삭제되어서 재로그인이 필요하다.+
리프레시 토큰이 유효한 경우 : 리프레시 토큰을 검증하여, 새로운 엑세스 토큰을 발급한다.+
리프레시 토큰이 만료 된 경우 : 현재 로그인이 무효화 되며 재로그인 필요하다.리프레시 토큰이 만료된 경우
+
엑세스 토큰이 유효한 경우 : 엑세스 토큰을 검증하여, 새로운 리프레시 토큰을 발급한다.엑세스 토큰이 탈취 된 경우
리프레시 토큰이 탈취 된 경우
둘 다 유출 된 경우
방법이 없다. 사실이 확인 되는데로 둘 다 만료시키자.
탈취 방지를 위해서 http-only속성을 부여하자
쿠키 탈취를 막기위해 쿠키를 만들 때 아래와같이 HttpOnly = true
를 부여하거나,
Response.Cookies.Add(new HttpCookie("쿠키명")
{
Value = "쿠키 값",
HttpOnly = true
});
web.config에서 <httpCookies httpOnlyCookies="true" />
로 기본값을 true로 설정하자
캐시
복사본을 나와 물리적으로 가까운 곳에 두어서 빠르게 읽어오는 모든 형태를 말한다.
메일 인증코드처럼 양이 작고, 짧은 시간 존재하는 내용만 넣는것이 좋다. 반대로 채팅상담처럼 길게 남을 것을 넣는 것은 좋지 않다.
CDN Content Delivery Network
캐싱의 한 형태이다.
변하지 않는 웹 리소스의 복사본을 고객과 가까운 곳에 배치하는 서비스이다.
클라이언트에서 요청이 있다면, 콘텐츠를 캐싱해둔다. 이후 같은 요청이 있으면 캐싱한 것을 제공해서, 속도와 서버부하를 모두 잡는다.
AWS에서는 Cloud Front 라는 이름으로 서비스한다.
문제점이 끝도 없이 생긴다...
오늘 일어나서 정리하자
🌐 Access Token & Refresh Token 원리
JWT에서 Refresh Token은 왜 필요한가?
[Web] HTTP Only와 Secure Cookie 이해하기