JWT를 공부하다가
[헤더] . [페이로드] . [헤더+ 페이로드 + 시크릿 키] 로 암호화 해서 건네준다는 방식은 이해가 되었으나 보안적인 측면에서 생각할 여지가 남아서 이 글을 작성하게 되었다.

JWT?

서버에서 인증이 완료가 되면 JWT 토큰을 발행해주고 이 토큰을 클라이언트에게 넘겨주고 클라이언트는 요청을 보낼때 이 토큰을 쿠키에 담아서 요청을 하게 된다.

서버는 받은 토큰과 헤더와 페이로드와 다시 암호화한 결과를 비교하게 되는데 여기서 같다면 인증이 완료가 된 것이고, 인증되지 않으면 인가되지 않은 사용자이다.

그렇지만 이 토큰을 발행하고 인증 받는 과정에서 과연 JWT 토큰이 탈취가 되어도 안전하다고 할 수 있을까? 라는 생각이 들어서 JWT 토큰에 보안 보완점을 검색하게 되었다.

JWT를 세션에서 사용하지 말아야 하는 이유?

1. JWT 토큰은 설정하기 어렵기 때문에 설정을 잘 못하는 경우 모든 사용자에게 인가가 가능한 토큰을 발행 할 수도 있다고 한다.

2. JWT 토큰을 사용하면 세션이 종료된 후에 발행된 토큰을 무효화 할 방법이 없다.

Refresh Token , Access Token

JWT를 사용함에 있어서 Refresh 토큰과 Access 토큰 구조를 사용하게 된다

Access 토큰은 클라이언트가 api를 이용할 때 사용되는 인증을 위한 토큰이고
Refresh 토큰은 서버가 가지고 있는 토큰이다.

Access 토큰을 하나만 가지고 있다고 가정하고 만약 이 access 토큰이 공격자로부터 탈취 당하게 된다면 서버 측에서는 이 탈취당한 토큰을 공격자가 마음대로 사용을 해도 클라이언트인지 공격자인지 구분을 할 수가 없다.

토큰이 탈취 당하게 되면 이 Access 토큰이 유효한 기간동안 공격자는 인증을 받은 상태가 되게 된다.

그렇다고 이 유효한 기간을 짧게 설정하게 된다면 클라이언트는 계속해서 인증을 해야하는 매우 귀찮은 상황에 놓이게 된다.

그래서 이 때 좀 더 보안적으로 보완하려고 생겨난 것이 Refresh 토큰이다.

이 문제를 해결하려면

1. 어떤 공격이 일어나고 있는지 감지
2. 공격 자체를 줄인다.

Access 토큰 단일으로는 공격자인지 클라이언트인지 구분이 불가능하므로 1번 방법으로는 이 문제를 해결 할 수가 없다. 따라서 2번 방법으로 이 문제를 해결해야 하는 것이다.

1. 초기 로그인시 Refresh(긴 시간) 토큰과 Access(짧은 시간) 토큰을 발행한다.
2. 클라이언트로부터 요청이 오면 Refresh 토큰이 유효한 기간동안 Access 토큰이 만료가 되었다면 새로운 토큰을 발행해주고 아니라면 요청을 승인한다.

요청이 만료가 되었더라도 새로운 토큰을 Refresh 토큰에서 발행해주게 된다. 만료가 되지 않았다면 요청을 받게 된다.

Access 토큰이 탈취가 되어도 Refresh 토큰 존재의 유무 때문에 짧은 시간으로 설정하므로 공격 횟수를 줄일수 있게 되는 것이다.

따라서 서버 입장에서는 Refresh 토큰이라는 임시 방어막 하나가 더 생겨서 보안취약점을 보완 할 수 있는 것이다.