Day38
로그인 기능을 이용 할때 access토큰을 이용해서 유저 정보를 인증 하는 법을 배웠고 그 토큰을 임시적으로 로컬스토리지에 담아서 사용하는 법을 익혀 왔다.
Access Token(JWT)를 통한 인증 방식을 할 경우 보안에 취약하고
유효기간이 짧은 Token의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 Token을 발급받아야 한다.
그러나 유효기간을 늘리자면, 토큰을 탈취당했을 때 보안에 더 취약해지게 됩니다.
그래서 refreshToken을 이용해야 한다.
refreshToken
refreshToken은 같은 형태의 JWT이다.
처음에 로그인을 완료했을 때 Access Token과 동시에 발급되는 Refresh Token은 긴 유효기간을 가지면서, Access Token이 기간이 지났을 때 새로 발급해주는 열쇠이다.
과정
-
사용자 로그인
-
서버에서는 회원 DB에서 값을 비교합니다(보통 PW는 일반적으로 암호화해서 들어갑니다)
-
로그인이 완료되면 Access Token, Refresh Token을 발급 이때 일반적으로 회원DB에 Refresh Token을 저장
-
사용자는 Refresh Token은 안전한 저장소에 저장 후, Access Token을 헤더에 실어 요청을 보냅니다.
-
Access Token을 검증하여 이에 맞는 데이터를 보냅니다.
-
시간이 지나 Access Token이 만료.
-
사용자는 이전과 동일하게 Access Token을 헤더에 실어 요청.
-
서버는 Access Token이 만료됨을 확인하고 권한없음을 신호
Access Token 만료가 될 때마다 계속 과정 7~8을 거칠 필요는 없다.
-
사용자는 Refresh Token과 Access Token을 함께 서버로 보낸다.
-
서버는 받은 Access Token이 조작되지 않았는지 확인한후, Refresh Token과 사용자의 DB에 저장되어 있던 Refresh Token을 비교합니다. Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 발급.
- 서버는 새로운 Access Token을 헤더에 실어 다시 API 요청을 진행
끝으로
기존의 Access Token로만 했을 때보다 보안상이나 Refresh 되는 과정 덕분에 로그인을 계속해서 하는 과정이 없어졌다.
단지 간단한 원리만 배웠지만 흥미도 가면서 내가 백엔드까지 해낼 수 있을까..? 생각이 든다.
