Refresh Token 연습중, 개선할 점 & 의문점들

 

1. 로그인하면 Access Token, Refresh Token을 발급한다 (response로 Frontend에 보내준다)

   * Access Token의 유효기간은 짧다. 이렇게 하지 않으면 Access/Refresh의 의미가 전혀 없다. 

 

2. Frontend는 Access Token, Refresh Token 모두 Local Storage에 저장하고, 

   => cookie에 담도록 변경하는 것이 권장된다. OK.

   평상시의 인증에는 (auth-middleware 인증이 필요한 API 호출시에는) Access Token만을 사용한다.

    * Access Token을 사용한다 = request header에 담아서 보낸다.

 

3. Access Token이 만료되었을 경우, Refresh API를 호출하여야 한다. 

 

FE 요구사항 정리

1. 인증 필요한 API 요청시엔,  request header에 Access Token을 담아서 요청

2. Access Token 인증이 실패할 경우, Body에 Refresh Token을 담아서 Refresh API 요청

     => 새로운 Access Token 발급되므로 1. 에서 요청했던 API를 재요청.

3. Refresh Token 인증도 실패할 경우 로그인 페이지나 메인 페이지로 Redirect

 

   => 이 부분을 백엔드가 자동화할 수 없는지?

        FE에서 Access Token 만료여부를 검사하고 Refresh 호출하는 과정을 서버가 해결해줄 수 있는지?

   => 할 수 있으나 하면 안됨.그렇게 하면 Refresh Token 사용의 의미가 하나도 없어짐.

   Frontend에서 Refresh API를 호출시 request body에 Refresh Token을 담아 보내주어야 한다. Cookie로 해결.

   Refresh API 요청을 받으면, Refresh Token을 verify 하고 Access Token을 새로 발급한다. 

   * 사용자 입장 : Refresh Token은 Local Storage 혹은 cookie에 저장되어 있을 것이다. 

   * 서버 입장 : Refresh Token은 user DB에 보관해뒀고, 사용자가 보내는 Refresh Token과 비교할 것이다. 

 

  서버가 이 부분을 자동화 하려면 (하지 말 것)

  1) 사용자의 Local storage 혹은 cookie에 있는 refresh token에 접근이 직접 - FE 의 요청 없이 - 가능해야 한다. 

      => 방법은 있을 것 같지만 이렇게 해두는 것은 옳은가? 옳지 않음. 

  2) Access Token 인증이 실패할 때 Refresh API 에 해당하는 내용을 실행하게 하면 된다. 

 

4. Refresh Token도 만료된 상황을 테스트해볼 것.

: 인증 실패임. 새로 로그인해야 함. (OK. 이게 맞음)

   

추가 의문점들

1) Refresh Token을 사용자 DB에 저장해두는 것이 좋은가?

 - 지금은 DB에는 토큰을 관리하지 않고 있음. 넣었음. 

   지금으로선 R.Token DB에 안 넣어두면 Refresh할 때 엉터리 Access Token 생성하게 됨.

 

   Refresh 할 때, Access Token 새로 생성하면서 사용자 식별이 필요, 이때 refresh token이 key가 되어주어야 한다.

   (기존의 Access Token은 만료된 상태이므로)

  => 이거 다르게 구현할 방법은 없는가?