1. JWT

1.1 Access Token과 Refresh Token

JWT 토큰은 유저의 신원이나 권한을 결정하는 정보를 담고 있는 데이터 조각

JWT 토큰 인증방식은 비밀키(개인키 or 대칭키)로 암호화

탈취당했을 경우 문제가 발생

• JWT 토큰을 탈취한 사람은 마치 신뢰할만한 사람인 것처럼 인증을 통과할 수 있기 때문
• 심지어 본 주인인 클라이언트와 탈취한 사람을 서버는 구분할 수 없음
• 따라서 유효 기간을 두어야하는 것

<aside> 💡 유효기간을 짧게 두면 사용자가 로그인을 자주 해야하므로 사용자 경험적으로 좋지 않고, 유효기간을 길게 두면 보안상 탈취 위험에서 벗어날 수 없음

해결법은 유효기간이 다른 JWT 토큰 2개(Acses Token과 Refresh Token)을 두는 것

</aside>

• Access Token의 유효기간은 짧음.
• Refresh Token의 유효기간은 김.
• 평소에 API 통신할 때는 Access Token을 사용하고, Refresh Token은 Access Token이 만료되어 갱신될 때만 사용

<aside> 💡 통신과정에서 탈취당할 위험이 큰 Access Token의 만료 기간을 짧게 두고 Refresh Token으로 주기적으로 재발급함으로써 피해을 최소화

</aside>

1.2 서버 클라이언트 통신

1. 로그인 인증에 성공한 클라이언트는 Refresh Token과 Access Token 두 개를 서버로부터 받음

2. 클라이언트는 Refresh Token과 Access Token을 로컬에 저장

3. 클라이언트는 헤더에 Access Token을 넣고 API 통신. (Authorization)

   3.1 요청마다 Access Token과 Refresh Token을 같이 넘기고 액세스 토큰이 만료된 경우 리프레시 토큰을 검증하여 재발급 받는 방법도 존재

4. 일정 기간이 지나 Access Token의 유효기간이 만료

   4.1. Access Token은 이제 유효하지 않으므로 권한이 없는 사용자가 됨

   4.2. 클라이언트로부터 유효기간이 지난 Access Token을 받은 서버는 401 (Unauthorized) 에러 코드로 응답

   4.3. 401를 통해 클라이언트는 invalid_token (유효기간이 만료되었음)을 알 수 있음

5. 헤더에 Access Token 대신 Refresh Token을 넣어 API를 재요청