로그인 방식은 크게 두가지로 나뉜다. (다른 방법도 있긴 함)
- 역사와 전통의 세션 로그인
- 무상태의 JWT 로그인
세션 방식
사실 처음 프로젝트라면 세션 로그인 방식을 직접 구현하는게 더 안전하고 간결하다. 개인적으로 좀더 쉽고 세션을 저장할 저장소 (메모리)에 직접 접근하여 세션을 관리하는 방식이기 때문에 안전하다.
JWT 토큰 방식
그렇다면 JWT 방식은 어떤 장점이 있을까?
JWT의 구조는 개미의 머리 - 가슴 - 배 형식처럼 Header(암호화 알고리즘) - Payload(데이터 원본) - Signature(전자서명) 으로 이루어져 있다. (점으로 구분)
또한 JWT 방식은 위변조 방지를 위해 전자서명 (Signature) 기술을 사용한다.
헤더와 페이로드 부분은 암호화가 아니라 그냥 단순 Base64 인코딩 타입으로 인코딩 된 상태기 때문에 누구나 온라인 툴로 복호화 가능하다. 그렇게 때문에 중요한 데이터는 토큰의 payload에 담으면 안됨.
JWT의 꽃은 Signature 부분이다.
서버는 비밀키 (Secret) 를 관리하고 있는데, 헤더 + 페이로드 + 비밀키를 하나로 말아 특정 알고리즘 (예를 들면 SHA512 등) 을 돌려 Signature 값을 계산해낸다. 서버가 이 비밀키를 털리면 모든 데이터를 털릴 수 있기 때문에 반드시 비밀키가 탈취되지 않도록 주의해야한다.
이러한 Signature은 단방향 암호화 방식이라 그 자체만으로는 비밀키를 알아낼 수 없기 때문에, 다음과 같은 방식으로 인증을 진행한다.
- 수신된 토큰의 Header + Payload 를 가져온다.
- 서버가 자신의 비밀키를 토대로 토큰에서 가져온 Header + Payload 을 이용하여 Signature 값을 다시 계산한다.
- 이때 다시 계산한 Signature와 원본 Signature 을 비교하여 무결성을 검증하고 서버가 발급한 토큰이 맞음을 검증한다.
- 이때 단 1비트라도 변경이 되었다면 시그니처 값은 절대 일치할 수 없게 되므로 서버가 이때는 해당 토큰이 위변조 되었음을 감지한 후 요청을 거부한다.
결론적으로 오직 서버만이 가진 비밀키를 이용한 Signature 검증을 통해 토큰의 무결성과 서버발급 인증을 보장하는 방식이다.
JWT 방식은 상태가 없다 (Stateless).
그렇기 때문에 세션 방식과 다르게 서버측에서 해당 사용자의 인승 상태를 별도로 저장하거나 기억하지 않는다. 또한 토큰 자체에 이미 모든 정보가 다 담겨있다.
JWT 가 상태를 저장하지 않기 때문에, 서버는 단순히 해당 클라이언트의 토큰 자체의 유효성 (Signature) 만 검증하면 된다.
별도의 저장소가 필요 없기 때문에 실제 저장소 (메모리)를 뒤지는 일을 줄일 수 있기 때문에 스레드나 커넥션을 아낄 수 있다. (스레드나 커넥션은 Cost 가 크기 때문)
JWT 방식은 그래서 서버를 여러대로 수평확장하는데 유리하고, 어떤 서버가 요청을 받더라도 서버에는 유일한 비밀키가 하나 존재하기 때문에 확장에 매우 유리하다.
내가 진행하는 수강신청 시스템 프로젝트는 특정 시간에 극단적으로 트래픽이 많이 몰리는 환경이다. 세션방식을 사용하게 되면 매 요청마다 메모리를 타야하는 일이 발생하게 되고, 너무 많은 사용자가 세션을 만들게 되면 메모리 오버플로우가 발생할 수도 있다.