세션 기반 인증과 토큰 기반 인증을 비교해서 설명해 주세요.
세션 기반 인증
세션 기반 인증은 사용자의 인증 정보가 서버의 세션 저장소에 저장되는 방식이다.
사용자가 로그인을 하면 해당 인증 정보를 서버의 세션 저장소에 저장하고, 사용자에게 저장된 세션 정보의 식별자인 Session ID를 발급한다. 발급된 Session ID는 브라우저에 쿠키 형태로 저장되지만, 실제 인증 정보는 서버에 저장되어 있다.
브라우저는 인증 절차를 마친 이후의 요청마다 HTTP Cookie 헤더에 Session ID를 함께 서버로 전송한다. 서버는 요청을 전달받고, Session ID에 해당하는 세션 정보가 세션 저장소에 존재하면 해당 사용자를 인증된 사용자로 판단한다.
토큰 기반 인증
세션 기반 인증이 인증 정보를 서버에 저장하는 방식이라면 토큰 기반 인증은 인증 정보를 클라이언트가 직접 가지고 있다. 이 때 인증 정보가 토큰 형태로 브라우저의 로컬 스토리지에 저장된다.
토큰 기반 인증에서는 사용자가 가지고 있는 토큰을 HTTP의 Authorization 헤더에 보낸다. 이 헤더로 수신한 서버는 토큰이 위변조 되었거나, 만료 시각이 지나지 않았는지 확인한 후 토큰에 담겨있는 사용자 인증 정보를 확인해 사용자를 인가한다.
인가 (Authorization)
인가는 인증 작업 이후에 행해지는 작업으로, 인증된 사용자에 대한 자원에 대한 접근 확인 절차를 의미한다.
세션 기반 인증 vs 토큰 기반 인증
사이즈
세션의 경우 Cookie 헤더에 Session ID만 보내면 되므로 트래픽을 적게 사용하지만, JWT는 사용자 인증 정보, 토큰 발급시각, 만료시각,토큰의 ID 등 담겨있는 정보가 많아 세션 방식보다 더 많은 네트워크 트래픽을 사용한다.
안전성과 보안문제
세션의 경우 모든 인증 정보를 서버에서 관리하기 때문에 보안측면에서 조금 더 유리하다. Session ID가 해커에게 탈취되어도 서버 측에서 해당 Session을 무효 처리하면 된다.
하지만 토큰의 경우 한 번 해커에게 탈취되면 해당 토큰이 만료될 때까지 피해를 입을 수 있다.
또 JWT 특성 상 토큰에 실린 Payload가 별도로 암호화되어 있지 않아 누구나 내용을 확인할 수 있어 민감한 데이터는 실을 수 없다.
확장성
토큰 기반 인증을 사용하는 이유는 이 확장성 때문인데,
일반적으로 웹 어플리케이션의 서버 확장 방식은 수평 확장을 사용한다. (한 대가 아닌 여러 대의 서버가 요청을 처리 )
이때 별도의 작업을 해주지 않으면 세션 기반 인증 방식은 세션 불일치 문제를 겪게 된다.
하지만 토큰 기반 인증 방식의 경우 클라이언트가 저장하는 방식이기 때문에 이러한 세션 불일치 문제로부터 자유롭다.
이런 특징으로 HTTP의 비상태성(Stateless)를 그대로 활용할 수 있고, 높은 확장성을 가질 수 있다.
서버의 부담
세션 기반 인증 방식은 세션 데이터를 직접 저장하고 관리해, 데이터의 양이 많아질수록 서버의 부담이 증가한다.
하지만 토큰 기반 인증 방식은 클라이언트가 직접 인증 데이터를 가지고 있어 유저의 수가 많아져도 서버의 부담이 증가하지 않는다.
