결론

refresh token은 브라우저, 클라이언트단에 저장하지 않는다.(서버 관점엔 response로 보내지 않는다.)
- 리프레시 토큰이 일회용인가, refresh token rotation
브라우저에서 사이트 최초 접근시, 쿠키 or localstorage의 access token의 유효함을 서버에 확인하고, (/api/user/reissue)
1. 브라우저 access token 미존재(undefined or null) ⇒ 해당 브라우저로 로그인한 적이 없음
  - 로그인 및 회원가입 페이지
2. access token 유효
  - access token, refresh token 재발행
    - (3분전에 로그인했는데, 바로 재발행하는게 필요없는 작업? 부하를 늘리는거 같아서 싫긴함)
    - 부하가 얼마나 걸리는지 확인해볼 필요가 있겠다.
  - 갱신 후 새로운 access token만 클라이언트로 반환(새로 발행된 refresh token은 서버, 사실상 db에만 존재)
  - (프론트단에서) 자동로그인 처리 & 메인페이지 이동
3. access token 만료, 관계되는 refresh token 유효
  - 클라이언트도 refresh token을 요구하나 ? 아니면,
  - access token, refresh token 재발행, 갱신 후 새로운 access token만 클라이언트로 반환(새로 발행된 refresh token은 서버, 사실상 db에만 존재)
  - 자동로그인 처리 & 메인페이지 이동
```
else {

            // access token 30분, refresh token 2주
            // 로그인한지 31분 후 들어옴,
                // 재발행을 해서 refresh token 2주 + 31분
                // 2주안에 들어오기만 하면, 그 시점부터 다음 2주도 자동로그인이 가능하다. 연장해주는거야

                    val data = tokenRepository.getDataByAccessToken(token);
                    if (jwtTokenProvider.validateToken(data.refreshToken)) {
                        // access token는 만료,  refresh token는 유효

//                        data.id를 대상으로 access token, refresh token을 재발행 해주는거지

                        val newToken = ~~~~~;

                        Authentication authentication = jwtTokenProvider.getAuthentication(newToken);
                        SecurityContextHolder.getContext().setAuthentication(authentication);

                    }

                    else {
                        // 로그인, 회원가입 페이지로 이동
                    }

        }
```
4. access token 만료, 관계되는 refresh token 만료
  - 로그인 및 회원가입 페이지 401 error forbidden
리팩토링 관련
- endpoint = controller method name = service method name

논의사항

필요한 기능
- 브라우저 쿠키, localstorage 내에 access token, refresh token 저장
  - https://velog.io/@yiseul/쿠키-세션-캐시-로컬스토리지의-차이
  - 둘다 저장하면, 나누는 이유가 없다
- 사이트 최초 접근시 해당 쿠키의 refresh token을 서버로 보내(엔드포인트: /api/user/reissue) 만료여부 확인
  - 만료X, 유효한 리프레시 토큰일 경우,
    - 서버에선 현 시점을 기준으로 한 access token, refresh token 재발행 및 클라이언트로 리턴
    - 클라이언트에선 재발행, 새로 발행받은 access token, refresh token을 쿠키에 저장
    - 쿠키에 저장된 access token 값을 header authorization의 value로 보냄
    - 메인페이지 화면으로 이동
  - 만료O, 유효하지 않은 리프레시 토큰일 경우
    - 로그인 및 회원가입 화면으로 이동
- 보안화된 요청의 액세스 토큰이 만료된 경우(30분전 로그인, 30분 후 어떤 api 요청 시)
  - axios interceptor를 통해 response가 401에러가 발생한 경우, /api/user/reissue 요청 및 access token, refresh token 재발행 및 쿠키에 저장 후, 에러가 발생한 요청을 재요청
케이스
- access token, refresh token in cookie
  - undefined, undefined
    - 로그인 및 회원가입 화면
  - 유효, 유효
    - 자동로그인 처리 및 메인페이지 화면
  - 만료, 유효
    - refresh token과 함께 /api/user/reissue 요청 및 access token, refresh token 재발행 및 쿠키에 저장
    - 자동 로그인 처리 및 메인페이지 화면
  - 만료, 만료
    - refresh token과 함께 /api/user/reissue 요청 했으나 에러 발생
    - 로그인 및 회원가입 화면

결론

논의사항

access token의 유효함을 어떻게 확인하나 ?

refresh token의 유효함을 어떻게 확인하나 ?