jwt 리플리쉬 토큰 관련해서 이해가 안가는부분이 있어 한번 더 질문합니다
본문
1. 사용자가 ID , PW를 통해 로그인합니다.
2. 서버에서는 회원 DB에서 값을 비교합니다(보통 PW는 일반적으로 암호화해서 들어갑니다)
3~4. 로그인이 완료되면 Access Token, Refresh Token을 발급합니다. 이때 일반적으로 회원DB에 Refresh Token을 저장해둡니다.
5. 사용자는 Refresh Token은 안전한 저장소에 저장 후, Access Token을 헤더에 실어 요청을 보냅니다.
6~7. Access Token을 검증하여 이에 맞는 데이터를 보냅니다.
8. 시간이 지나 Access Token이 만료됐다고 보겠습니다.
9. 사용자는 이전과 동일하게 Access Token을 헤더에 실어 요청을 보냅니다.
10~11. 서버는 Access Token이 만료됨을 확인하고 권한없음을 신호로 보냅니다.
12. 사용자는 Refresh Token과 Access Token을 함께 서버로 보냅니다.
13. 서버는 받은 Access Token이 조작되지 않았는지 확인한후, Refresh Token과 사용자의 DB에 저장되어 있던 Refresh Token을 비교합니다. Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 발급해줍니다.
14. 서버는 새로운 Access Token을 헤더에 실어 다시 API 요청을 진행합니다.
-------------------------------------------------------------------------------
12~ 13 번 부분이 이해가 안되는데요.
1) Refresh Token 토큰을 보내서 새로 발급해주는건 이해되는데
왜 Access Token 토큰을 함께 보내는거죠? 이미 Access Token 토큰은 만료되서
사라져있지 않나요?
(설마 Refresh Token 과 Access Token 토큰 두개다 DB에 저장해둬야 하는건 아니겠죠?;;)
2) 그리고 Refresh Token 토큰은 따로 db에 저장안해놔도 긴 유효기간때문에
사용 가능할꺼같은데 DB에 따로 저장은 안해도 되는건지요?
답변 1
1. 이중 안전이죠. 즉 현재 발행된 A1(access token) R1(refresh token)것을 발행자 입장에서는 알고 있는데, 이것이 노출되어서 다른 사람이 사용을 할려고 할 때, R1만 가지고 체크하면 뚤릴 가능성이 있을 것 같습니다. 즉 만료된 A1과 같이 와야, 이전 스테이트와 비교해서 정확한 확인이 가능할 것 같습니다.
2. 비교를 할려면 각 토큰이 DB에 저장되어 있어야 될 것 같은데요. (악세스 토큰도 서버에 저장이 필요?)
DB에 저장은 구현시에 어떻게 "토큰이 동일한지"를 체크해야 하는 부분에서 결정이 날것 같습니다.
단순 토큰값을 비교한다면 저장을 해야 되고, 각 유저별 시퀀스 값을 넣어서 그것을 체크하는 방법도 있을 것 같고..
이 부분은 구현된 사례를 좀 더 찾아봐야 될 것 같습니다.
참고로 지금까지 검색을 해 보면 Access token으로 구현된 사례가 많습니다. Refresh token사례는 Oauth2.0으로 된 별도의 Authorization Server인 경우가 많고요. 즉 단독으로 처리할 때는 굳이 어렵게 2가지 구현은???