앞선 과제에서는 매 요청마다 비밀번호를 보내 DB와 대조후 일치시에만 요청을 수행하였다. 하지만 매번 비밀번호를 담아 요청을 보내는것은 보안상 좋지않다. 그렇다면 어떠한 해결방법이있을까?
쿠키와 세션
쿠키 : 클라이언트에 저장될 목적으로 생성한 작은 정보를 담은 파일
세션: 서버에서 일정시간 동안 클라이언트 상태를 유지하기 위해 사용
쿠키와 세션을 따로 생각하면 어떻게 활용이 될지 감이 안잡히지만 두개를 같이 사용한다고 가정해보자. 최초 요청에서 들어온 비밀번호를 받은 서버는 어떠한 재 요청시 비밀번호 대신 다른 데이터 (쿠키)를 통해 별도의 저장공간(세션)의 데이터와 대조하여 인가한다.다시 말해 최초 요청에서 DB의 비밀번호 대조를 통해 인가된 클라이언트에 생성된 쿠키를 담아 반환하고 해당 클라이언트가 쿠키와 함께 재요청시 세션에 저장된 쿠키의 데이터를 대조하여 인가한다는 말이다. 어떻게 보면 일반 비밀번호 대조와 메커니즘은 비슷해보이지만 우선 생성된 쿠키는 유니크한 이름과 만료기한이 정해져있어 데이터유출이 되었을시 비밀번호보다 안전하다는것을 알수있다.
하지만 쿠키와 세션도 가지고있는 문제점이 있는데 우선 쿠키는 비밀번호보다는 위험이 작더라도 우선적으로 데이터의 정보가 클라이언트에 저장되기때문에 쿠키의 데이터를 쉽게 조작될수있다는 위험성이 있으며 세션의 경우 재요청이 이뤄질때도 마찬가지로 저장소의 데이터를 조회해 대조해보는 과정이 매 요청마다 시행이되기때문에 클라이언트의 수가 많아질경우 문제가 발생할수있다.
JWT(Json Web Token)
JWT(Json WEb Token)은 JSON 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim기반의 Web Token이다. 일반적으로 앞서 설명한 쿠키저장소를 이용해 JWT를 저장하여 사용한다.
JWT는 기존 세션기반 로그인방식에서 다수의 서버가 사용될때 세션 저장소의 부하를 낮추기 사용된다. 말로는 어려우니 그림을 통해 알아보자.
다수의 클라이언트로부터 오는 요청을 로드밸런서를 통해 한 서버에만 부하가 몰리지않도록 요청을 나누고 모든 서버가 세션저장소에 저장된 클라이언트의 정보조회를 통해 로그인을 인증한다고 할때
우리는 쉽게 세션저장소에 큰 부하가 걸릴것이라는것을 예측할수있다.
이때 JWT를 사용하여 로그인정보를 Server에 저장하지않고 Client에 로그인 정보를 JWT로 암호화하여 저장함으로써 해당 JWT를 검증함으로써 인증한다고 하면 부하를 낮출수있다.이때 암호화된 JWT는 Secret Key를 통해 조작할수있기때문에 모든서버는 같은 Secert Key를 가지고 JWT를 조작한다.
JWT 장점, 단점
장점
- 동시 접속자가 많을 때 서버 측 부하 낮춤
- Client, Server가 다른 도메인을 사용할때(JWT검증은 도메인을 고려하지않음)
단점
- 구현 복잡도 증가
- JWT에 담는 내용이 커질 수록 네트워크 비용 증가(클라이언트 -> 서버)
- 기 생성된 JWT를 일부만 만료시킬 방법이 없음
- Secret Key 유출 시 JWT 조작가능
