<div id="readability-page-1" class="page"><div><h2 id="도입한-전략">도입한 전략</h2>
<p><a href="https://tecoble.techcourse.co.kr/post/2021-05-22-cookie-session-jwt/">Tecoble의 인증방식과 관련된 포스트</a>를 보면 JWT의 단점을 극복하기 위한 다양한 보안 전략을 제시하는데 그 중 <strong>Refresh Token</strong>의 경우 아래와 같은 흐름으로 진행된다. </p>
<ol>
<li>클라이언트가 로그인 요청을 보내면 서버는 Access Token과 더 긴 만료 기간을 가진 Refresh Token을 발급한다.</li>
<li>Access Token이 만료되면 클라이언트는 Refresh Token을 사용하여 Access Token의 재발급을 요청한다.</li>
<li>서버는 DB에 저장된 Refresh Token과 비교하여 유효한 경우 새로운 Access Token을 발급하고, 만료된 경우 사용자에게 로그인을 요청한다.</li>
</ol>
<h2 id="로그인-flow">로그인 flow</h2>
<p>위의 전략을 <strong>뚝딱 프로젝트</strong>에 적용해보자!👀</p>
<ol>
<li>사용자가 로그인 버튼을 클릭하고 아이디와 비밀번호를 입력한다.</li>
<li>회원가입이 되어있는 사용자라면 뚝딱 DB에서 사용자를 조회하고, 회원가입이 되어있지 않은 사용자라면 회원가입이 되어있지 않다는 에러코드를 반환한다.</li>
<li>사용자 식별값(userId)를 이용해서 뚝딱 Access Token &amp; Refresh Token을 발급한다.</li>
<li>클라이언트에게 토큰을 전송하는데, Access Token은 response body로, Refresh Token은 http only로 설정한 쿠키에 저장한다.</li>
</ol>
<ul>
<li>클라이언트 쪽의 credentials을 true로 설정해준다. </li>
<li>https 적용 이후에는 secure 설정을 해준다.</li>
</ul>
<h2 id="access-token이-만료될-경우">Access Token이 만료될 경우</h2>
<ol>
<li>쿠키를 확인하여 Refresh Token을 가져온다.</li>
<li>Refresh Token의 유효성을 검증한다.<br>
2-1. 유효한 Refresh Token이라면 클라이언트에게 토큰 재발급이 필요하다는 예외를 던진다. → 클라이언트가 토큰 재발급 요청 → Access Token 및 Refresh Token 재발급<br>
2-2. 유효하지 않은 Refresh Token이라면 로그인이 필요하다는 예외를 던진다. → 로그인</li>
</ol>
<ul>
<li>Refresh Token의 기간은 14일로 설정</li>
</ul>
<h2 id="새로운-환경에서-로그인을-시도할-경우">새로운 환경에서 로그인을 시도할 경우</h2>
<ol>
<li>기존 Refresh Token을 폐기하고 새로운 토큰으로 대체한다. </li>
<li>유효한 토큰을 여러개 유지한다. (논의 필요)</li>
</ol>
<h2 id="로그아웃">로그아웃</h2>
<ol>
<li>Refresh Token이 유효한 경우 → redis에서 Refresh Token을 삭제한다. </li>
<li>maxAge가 0인 같은 이름의 쿠키를 전송한다.</li>
</ol></div></div>

janeljs.log

도입한 전략
Tecoble의 인증방식과 관련된 포스트를 보면 JWT의 단점을 극복하기 위한 다양한 보안 전략을 제시하는데 그 중 Refresh Token의 경우 아래와 같은 흐름으로 진행된다. 
클라이언트가 로그인 요청을 보내면 서버는 Access Token과 더 긴 만료 기간을 가진 Refresh Token을 발급한다.
Access Token이 만료되면 클라이언트는 Refresh Token을 사용하여 Access Token의 재발급을 요청한다.
서버는 DB에 저장된 Refresh Token과 비교하여 유효한 경우 새로운 Access Token을 발급하고, 만료된 경우 사용자에게 로그인을 요청한다.
로그인 flow
위의 전략을 뚝딱 프로젝트에 적용해보자!👀
사용자가 로그인 버튼을 클릭하고 아이디와 비밀번호를 입력한다.
회원가입이 되어있는 사용자라면 뚝딱 DB에서 사용자를 조회하고, 회원가입이 되어있지 않은 사용자라면 회원가입이 되어있지 않다는 에러코드를 반환한다.
사용자 식별값(userId)를 이용해서 뚝딱 Access Token & Refresh Token을 발급한다.
클라이언트에게 토큰을 전송하는데, Access Token은 response body로, Refresh Token은 http only로 설정한 쿠키에 저장한다.
클라이언트 쪽의 credentials을 true로 설정해준다. 
https 적용 이후에는 secure 설정을 해준다.
Access Token이 만료될 경우
쿠키를 확인하여 Refresh Token을 가져온다.
Refresh Token의 유효성을 검증한다. 
2-1. 유효한 Refresh Token이라면 클라이언트에게 토큰 재발급이 필요하다는 예외를 던진다. → 클라이언트가 토큰 재발급 요청 → Access Token 및 Refresh Token 재발급
2-2. 유효하지 않은 Refresh Token이라면 로그인이 필요하다는 예외를 던진다. → 로그인
Refresh Token의 기간은 14일로 설정
새로운 환경에서 로그인을 시도할 경우
기존 Refresh Token을 폐기하고 새로운 토큰으로 대체한다. 
유효한 토큰을 여러개 유지한다. (논의 필요)
로그아웃
Refresh Token이 유효한 경우 → redis에서 Refresh Token을 삭제한다. 
maxAge가 0인 같은 이름의 쿠키를 전송한다.

[Tuktalk Project #1] Refresh Token을 이용해서 로그인 유지하기

댓글