session
세션은 서버측에서 사용자의 정보를 저장하는 방법이다.
브라우저가 연결되면 클라이언트에 대한 세션을 확보하고, 연결이 종료되면 세션을 닫는다.
- 로그인 요청
- 로그인 처리 (세션에 사용자 정보 저장)
- 로그아웃 (세션에 사용자 정보 제거)
세션은 사용자의 정보가 서버에서 보관되는 방식이기에, 보안상으로도 안전하다고 볼 수 있다.
기본적으로 세션은 서버의 메모리에서 사용자의 정보를 저장하지만, 하드 디스크나, DB까지 다양하게 세션 정보들을 저장해둘 수 있다.
JWT
세션 방식은 편리하지만, REST API는 stateless 하기에, 사용자의 정보를 저장하지 않는다.
즉 세션은 사용하지 않는데, 로그인을 어떻게 유지하나?
토큰을 활용하는 방식이 해결책이다.
JWT(JSON Web Token)은 이때 사용되는 토큰 방식이라고 볼 수 있다.
간단히 말하자면, 티켓은 사용자에게 있고, 티켓 검수만 서버에서 하는 방식이다.
1. 로그인이 요청됨
2. 사용자에게 토큰 발급
3. 사용자가 서버에게 요청 시 토큰을 함께 전송
4. 서버는 토큰을 검수하여 사용자 정보 확인
근데 만약에 토큰을 위조한다면?
JWT 구조
JWT는 헤더, 페이로드, 시그니처 구조로 이뤄져있다.
페이로드 부분은 사용자의 정보가 인코딩된 부분이고, 디코딩하면 아이디, 닉네임, 권한 등 사용자의 정보를 얻을 수 있다.
이 부분을 조작하게 되면 상당히 보안상 위험해보인다.
하지만 헤더와 시그니처를 통해서 해결이 가능하다.
헤더는 암호화 알고리즘이 표시되어 있다.
다시 말해, 서버는 클라이언트의 정보를 저장하지 않지만, 검수를 위해 비밀키를 가지고 있다.
이 비밀키와 헤더, 페이로드를 조합하여 암호환 결과를 시그니처와 비교하고, 일치하는지 확인 하는 과정때문에 토큰을 조작하여도 검수가 가능하다는 점이다.
refresh token
만약 JWT 자체가 악성 유저에게 넘어가면?
서버는 실제로 티켓을 들고 온 사람이 원래 주인인지, 악성 유저인지 구별을 할 수 없다.
이 떄 해결할 수 있는 방법이 refresh token이다.
- access token과 refresh token을 함께 발행한다.
- access token의 만료기간을 짧게 설정한다.
- access token이 만료되었어도, refresh token(유효기간 길게)이 유효하다면 다시 access token을 발행해준다.
그리고 refresh token이 탈취되는 경우를 예방하고자, 서버의 DB에 refresh token을 저장하고 다른 악성 유저에게 노출이 되었다면 refresh token을 삭제하면 된다.
session vs JWT
위 설명을 보면 세션은 비교적 아주 간단해보이고, REST API에서 stateless한 것을 추구하지만 refresh token을 저장하게 되면서 stateful한 환경이 되어버린 셈이다.
애초에 REST API는 완벽한 stateless 환경이 아니다.
서버 부하
많은 사용자가 몰리게 되면, 세션은 그 만큼 많은 세션을 관리하게 되므로, 서버에 큰 부담이 가지만 JWT는 서버에 큰 부담이 되는 경우가 없다.
분산 환경
예를 들어 로그인 서버와, 게시물을 확인하는 서버가 분리되어있다면, 게시물을 작성하려할 때, 로그인 정보를 게시물 서버에서는 확인할 수 없다(세션이 메모리에 있는 경우)
그렇지만 토큰 방식에서는 문제가 없다고 보면 된다.
결론
적절하게 잘 선택해서 사용하자
