- 권한을 검사하기 위해 토큰 종류 중 하나인 jwt사용
- 서버에서 유저 권한 상태를 유지하지 않고 토큰으로만 관리. 부하가 줄어듬
- jwt를 이용하면 토큰에 데이터를 저장해둘 수 있음
- 액세스 토큰은 통신에 자주 오가기 때문에 탈취당할 염려가 있음
- 그래서 액세스 토큰은 짧은 만료기간을 가짐
- 하지만 액세스 토큰의 짧은 만료기간을 통해 재로그인 과정을 자주 거쳐야함
- 그에 대한 방안으로 액세스 토큰은 짧은 만료기간을 두고, 상대적으로 긴 만료기간을 가진 리프레쉬 토큰을 가짐
- 로그인을 통해서 액세스 토큰을 계속 재발급 받는 과정을, 토큰 리프레쉬 과정을 통해서 줄일 수 있음
- 리프레쉬 토큰은 액세스 토큰이 만료되었을 때, 액세스 토큰을 재발급받을 때만 사용함. 통신에 자주 오가지 않음
- 사실 https를 이용하기 때문에 토큰이 탈취될 가능성이 높진 않음
- 토큰 저장 위치 및 요청은 헤더를 이용할 것임
- 쿼리스트링에 토큰을 남긴다면 로그가 남기 때문
1. 클라 ---- 로그인 요청을 한다 ----> 서버
2. 클라 <---- 액세스 토큰과 리프레쉬 토큰을 발급해준다. 리프레쉬 토큰은 디비에도 저장해둔다. ---- 서버
리프레쉬 토큰을 클라이언트에도 발급해주는 이유 : 액세스 토큰이 만료되었을 때, 디비에 저장해둔 리프레쉬 토큰으로만 검증하고 리프레쉬를 한다면, 액세스 토큰을 가진 모든 사용자가 토큰을 리프레쉬 할 수 있기 때문에, 리프레쉬 토큰으로 재요청해야함
리프레쉬 토큰을 디비에도 저장하는 이유 : 디비에도 저장하는 것은 선택이겠지만, 만약 리프레쉬 토큰까지 탈취당한다면, 리프레쉬 토큰을 가진 모든 사용자가 액세스 토큰을 계속 재발급할 수 있음. 따라서 유효한 리프레쉬 토큰을 디비에 저장해두고 액세스 토큰을 재발급할 때, 리프레쉬 토큰도 재발급해준다면, 유효한 리프레쉬 토큰은 하나만 가지고 있을 수 있어서 더 좋지 않을까싶음(리프레쉬 토큰을 검증할 때, 디비에 저장해둔 리프레쉬 토큰과도 비교)
3. 클라 ---- 액세스 토큰으로 api 요청을 한다 ----> 서버
4. 클라 <---- 액세스 토큰 만료 응답을 받는다 ---- 서버
3번 4번 과정은, 액세스 토큰의 만료 기간이 다가오면 setTimeout으로 자동으로 리프레쉬 요청을 해놓을 수도 있음
5. 클라 ---- 리프레쉬 토큰으로 액세스 토큰 재발급 요청을 한다 ----> 서버
클라이언트에서 넘어온 리프레쉬 토큰과 디비에 저장된 리프레쉬 토큰이 일치하는지 검증
리프레쉬 토큰이 유효한지 검증
액세스 토큰과 리프레쉬 토큰 갱신하여 재발급
6. 클라 <---- 갱신한 액세스 토큰과 리프레쉬 토큰을 발급해준다. ---- 서버
* 처음 학습할 때, 여기저기 글을 읽어보며 주관적으로 정리해본 내용입니다. 방법도 다양하고 정확한 내용이 아닐 수 있습니다.
'기타' 카테고리의 다른 글
| GitHub - Your account has been flagged. (0) | 2021.11.16 |
|---|---|
| virtualbox 0x80004005 오류 (0) | 2021.11.10 |