🔥 TIL - Day 69 JWT Refresh token 1

현재 진행중인 프로젝트는 JWT 토큰을 이용해서 인증을 수행하고 있다.
인증은 굉장히 민감한 부분이다. 토큰을 사용하는 경우 이 민감한 부분에서 이슈가 발생하기 쉽다.

📌 어떤 방법으로든 Access Token을 탈취당한다면?

현재 우리 서버의 경우 Access Token이 탈취당했다는 사실 자체를 알 수 없다.
탈취당했다는 사실을 알았다고 하더라도 할 수 있는 조치는 현재 발행된 모든 토큰이 검증 불가능하도록 하는 것 뿐이다.

여기서 문제는 이미 발행된 특정 토큰에 대해 서버는 어떤 조치도 할 수 없다는 것이다.

📌 Access Token의 보안상 취약점 해결 (만료기간을 짧게)

Access Token이 탈취당하더라도 발생 가능한 피해가 최소화 되도록 Access Token의 만료기간을 매우 짧게 하는 방법이다.

이렇게 하면 클라이언트는 매우 자주 다시 인증(로그인)을 해야 한다.

보안의 책임을 클라이언트에게 전가해서 불편함을 유발시키는 좋지않은 방법이다.

📌 Access Token + Refresh Token

Access Token의 만료기간을 짧게 가져가는 솔루션은 유지하면서 사용자의 불편함을 최소화하는 방법이다.

클라이언트는 인증에 성공하면 두 개 토큰을 발급받는다.

• Access Token: 인증에 사용되는 토큰
• Refresh Token: Access Token을 발급받기 위한 토큰

Access Token은 1시간 이내로 짧은 만료시간을 할당하고 Refresh Token에는 7일~30일 정도로 긴 만료시간을 할당한다.

매 요청마다 클라이언트는 두 토큰을 모두 헤더에 포함해서 오고 서버 측에서는 우선적으로 Access Token을 검증하고 Access Token이 만료되었다면 Refresh Token을 검증해서 새로운 Access Token을 생성하고 인증처리 후 새로운 Access Token을 내려준다.

📌 Refresh Token이 탈취당한다면 ?

Access Token의 만료기간을 짧게 가져가면서 자주 인증해야 하는 번거로움을 해결하기 위해 Refresh Token을 적용했다. 아직 문제가 있다.

Refresh Token이 탈취당한다면 ???

Access Token만 있었을 때 서버는 발급된 특정 Access Token을 무력화 시킬 방법이 없었다.
인증로직을 변경해서 발급된 모든 Access Token을 무력화시키는 정도가 최선일 것이다.

특정 클라이언트의 토큰을 무력화시킬 방법이 필요하다.

뭔가 특별한 방법이 있는 것은 아니다. Refresh Token을 서버에서 관리하는 것이다. (마치 세션처럼)

• 최초 인증시 Access Token과 함께 생성된 Refresh Token을 DB에 저장한다.
• 만료된 Access Token으로 요청이 온 경우 함께 전달된 Refresh Token을 검증하고 서버측 DB에서 조회한다.
• Refresh Token이 유효하고 DB에서도 조회가 된다면 REAL 제대로된 Refresh Token으로 판단한다.

Refresh Token이 저장된 DB의 특정 row를 삭제한다면 이미 발급된 Refresh Token은 무력화된다.

---

Next...

• Springboot Redis 연동 및 기본 연산 테스트
• Refresh Token DB에 저장하기 (Redis)