세션 기반 인증과 토큰 기반 인증 비교

1. 세션 기반 인증 (Session-Based Authentication)

특징

• 서버가 세션을 생성하고, 이를 서버의 메모리 또는 데이터베이스에 저장
• 사용자가 로그인하면 서버는 세션 ID를 생성해 클라이언트에 쿠키로 전달
• 클라이언트는 요청 시마다 세션 ID가 포함된 쿠키를 서버에 전달하여 인증한다
• 서버는 세션 ID를 기반으로 해당 사용자의 세션을 조회해 사용자의 인증 상태를 확인한다

장점

• 보안성: 세션 ID는 서버에만 저장되고, 클라이언트에서는 세션 ID만 갖고 있으므로 클라이언트에 민감한 정보를 저장하지 않아 상대적으로 안전하다
• 상태 유지: 서버가 인증 상태를 유지하기 때문에 상태 기반의 요청 처리에 적합하다

단점

• 서버 자원 소모: 모든 세션을 서버에서 유지해야 하므로, 사용자 수가 많아지면 메모리 사용량이 증가한다
• 스케일링 어려움: 서버가 세션을 직접 관리하므로, 여러 서버로 수평 확장하는 구조에서 세션 동기화가 필요할 수 있다.
• 크로스사이트 요청 위조 (CSRF) 취약성: 세션 기반 인증은 CSRF 공격에 취약할 수 있으므로 별도의 방어 조치가 필요하다

2. 토큰 기반 인증 (Token-Based Authentication)

특징

• 서버는 사용자 인증 후, 사용자 정보를 포함하는 JSON Web Token (JWT) 같은 토큰을 생성하여 클라이언트에 전달한다.
• 토큰은 클라이언트 측에 저장되며, 보통 HTTP 헤더에 포함되어 서버에 전달된다
• 서버는 요청을 받을 때마다 토큰을 검증하여 사용자 정보를 확인하고 인증을 처리한다
• JWT는 보통 유효 기간이 설정되며, 만료되면 새로 발급받아야 한다

장점

• 무상태성 (Stateless): 서버에 세션을 유지하지 않으므로 수평 확장이나 클라우드 환경에 적합하다
• 확장성: 서버 간에 세션 상태를 공유할 필요가 없어 마이크로서비스나 모바일 환경에서도 일관되게 사용할 수 있다
• CSRF 방어: 클라이언트가 HTTP 헤더에 토큰을 넣어 전송하므로 CSRF 공격에 대한 저항력이 더 크다

단점

• 보안 위험: 클라이언트에 민감한 정보를 담고 있으므로 토큰의 탈취 위험이 있으며, 이를 방지하기 위해 HTTPS를 통해 전송해야 한다
• 토큰 갱신: JWT는 만료 시간이 있어, 갱신이 필요할 경우 이를 구현해야 한다. 일반적으로 Access Token과 Refresh Token 방식을 사용한다
• 토큰 크기: JWT는 페이로드에 정보가 포함되어 크기가 클 수 있으며, 요청마다 이를 전송하면 네트워크 부하가 발생할 수 있다.