검색을 좀 더 해 보고 있습니다.

저와 같은 생각을 가지고 있는 사람도 있고...

https://zzossig.io/posts/etc/what_is_the_point_of_refresh_token/

해외쪽을 찾아보면, 리프레시 토큰의 장점은

1. Access Token을 짧게 하면,  사용자가 불편하고(매번 로그인해야.), 이것을 길게 하면, 토큰이 유출되었을 때의 불안감이 있죠. (아마도 매번 API콜할 때마다 헤더에 포함되다 보니, 찾을 가치가 있다고 하면 찾을 수가 있게죠.)

2. 쇼핑몰 같은 중요한 사이트라고 하면,  이 문제에 대한 대안으로 리프레시 토큰을 고려해서 보안성을 좀 더 높이는 쪽으로 가야 될 것 같습니다.

3. Access Token은 1시간, Refresh Token은 2주로 주고. (발급하는 방식은 같음).

   1. Access Token이 끝나면, Refresh Token을 보내서 Access Token을 발급 받음

   2. 발급시 Refresh Token은 암호화해서 데이타베이스에 저장해 놓음. 

   3. Refresh Token이 도착했을 때,  데이타베이스에 있는 저장된 토큰과 비교함.  틀리면 Access Token 발행 안함.

   4. Refresh Token이 유효한지 체크해서 Expire가 안되어 있으면, Access Token을 발행.

   5. 다른 디바이스에서 로그인 했을 때, 새로 발급된 Refresh Token이 데이타베이스에 저장됨으로 기존에 발급된 Refresh Token은 모두 무효가 됨.

   6. 데이타베이스에 암호화(해시)해서 저장하는 이유는 데이타베이스가 해킹 되었을 때를 대비해서 암호화해 둠.

   7.  로그아웃을 할 경우에는 클라이언트에서는 Access Token을 지우고, 서버에서는 데이타베이스에서 Refresh Token을 지움.

대략적으로 구현되는 방법 같습니다.

서버에서 각 개인별 발행된 토큰을 무효화 하는 방법은 없을 것 같습니다.  전체 토큰을 한번에 무효화는 시크릿 키를 바꿈으로 가능할 것 같습니다. (검색이 더 필요함.)

Refresh Token을 보낼때, 만료된 Access Token도 보낸다고 되어 있는데,  어차피 만료된 토큰을 굳이 보낼 필요가 없을 것 같음. (만료된 Access Token을 보낸다고 하면, 이것도 데이타베이스에 저장되어 있어야 되는데, 그렇게 되면 불필요한 데이타베이스 억세스가 생길 것 같은데,  2개의 토큰이 비교되면, 시큐리티는 좀 더 좋아질 것 같습니다.)