세션 기반 인증과 토큰 기반 인증, 보안 고려사항

이번주 첫번째 위클리 페이퍼

 - 세션 기반 인증과 토큰 기반 인증의 차이점과 각각의 보안 고려사항에 대해 설명하세요.

 

---

 

* 인증, 인가에 대해

인증(Authentication)

사용자가 본인이 맞는지를 검증하는 절차. 아이디와 비밀번호를 통해 로그인하는 과정 등..

 

인가(Authroization)

인증된 사용자가 시스템 자원에 대한 접근권한이 있는지 확인하는 절차. 어떤 방식으로 발급하고 저장할 것인가에 관한 방법.

세션 기반 인증과 토큰 기반 인증은 인가에 관련된 기술이라고 볼 수 있다.

 

---

 

세션 기반 인증

세션 기반 인증은 사용자의 인가 정보가 서버의 세션 저장소에 저장되는 방식임

사용자가 로그인을 하면, 서버는 해당 인가 정보를 세션 저장소에 저장한 후 세션 저장소의 식별자인 Session ID를 클라이언트측에 전달함

클라이언트는 전달받은 Session ID를 웹 스토리지 혹은 쿠키에 저장하고 인가가 필요한 요청시 함께 전달하게 된다

 

토큰 기반 인증

토큰 기반 인증은 정보를 서버가 추적하지 않고, 토큰만으로 권한을 판별하는 방식임

사용자가 로그인하면, 서버는 인가 정보를 담은 토큰을 발행한 후 클라이언트에게 전달한다.

클라이언트는 전달받은 토큰을 웹 스토리지 혹은 쿠키에 저장함.

JWT와 같은 대표적 토큰의 경우 디지털 서명이 존재해서 토큰의 내용이 위변조 되었는지 서버측에서 확인할 수 있음

위변조되지 않고, 유효기간이 지나지 않았다면 유효한 사용자로 판단한다.

 

---

 

세션 기반 인증과 토큰 기반 인증의 차이점 - 첫번째 요구사항

1. 사이즈

세션의 경우 브라우저로 세션 ID만 실어 보내면 되기 때문에 트래픽을 적게 사용함.

JWT(토큰 기반 인증)의 경우 사용자 인증 정보와 토큰의 발급시각, 만료시각, 토큰의 ID등이 담겨있는 정보가 세션ID에 비해 많기 때문에 세션 방식보다 훨씬 많은 네트워크 트래픽을 사용함.

한두명이면 모르겠지만 수많은 사람들의 토큰을 다룬다고 생각하면 확실히 차이가 난다!

Why JWTs Suck as Session Tokens(왜 JWT는 세션보다 개똥인가?)에 따르면, JWT에 iss, sub, nbf, exp, iat, jti, typ 클레임을 싣는 데 304바이트가 나왔다고 한다. 그에 비해 세션 ID는 6바이트만 나왔다고 함. 어마어마한 차이가 맞다!

 

2. 안정성, 보안 - 두번째 요구사항

세션 기반 인증의 경우 모든 인증 정보를 서버에서 관리하기 때문에 보안측면에서 조금 더 유리하다. 세션ID가 해커에게 탈취되는 경우가 발생해도 서버측에서 해당 세션을 무효하면 되기 때문.

그렇다고 세션 기반 인증이 무적인건 아니다. 어쨌든 쿠키 기반으로 세션 ID가 서버에서 관리되기 때문에 CSRF 공격에 취약하다.

따라서 세션 ID를 무작위로 생성하여 예측을 어렵게 하거나, HttpOnly 및 Secure 속성을 활용하여 쿠키 탈취를 방지하며,

세션의 유효기간을 짧게 설정할 수도 있고 CSRF 토큰을 활용해 방어할 수도 있다.

 

토큰 기반 인증의 경우 그렇지 않다. 토큰은 서버가 트래킹하지 않으며, 클라이언트가 모든 인증 정보를 가지고 있다.

따라서 토큰이 한번 해커에게 탈취된다면 해당 토큰이 만료되기 전까진 피해를 그대로 입을 수 밖에 없다.

JWT 특성상 토큰에 실린 Payload가 별도 암호화가 되어있지 않기 때문에, 누구나 내용을 확인할 수 있다. 따라서 Payload에는 민감한 데이터는 실을 수 없다고 한다. - > Payload에 실을 수 있는 데이터는 제한된다

하지만 세션 기반 인증의 경우, 모든 데이터가 서버에 저장되기 때문에 아무나 함부로 열람할 수 없다. 따라서 저장할 수 있는 데이터에도 제한이 없다.

 

3. 확장성

그럼 토큰 기반 인증이 더 불안정하니까 많은곳에서 세션 기반 인증을 쓰는것이 아닌가? 할 수 있는데, 그건 또 다른 이야기이다.

최근 모던 웹 어플리케이션이 토큰 기반 인증을 사용한다고 하는데, 그 이유가 확장성에 있다고 한다.

일반적으로 웹 애플리케이션의 서버 확장 방식은 수평 확장을 사용한다고 한다.

한대의 서버가 아닌 여러대의 서버가 요청을 처리하는 방식을 사용하는 것.

세션 기반 인증 방식의 경우 별도의 처리를 해주지 않으면 세션 불일치 문제를 겪게 된다.

이를 해결하기 위해 Sticky Session, Session Clustering, Session Storage 외부 분리 등의 작업을 해줘야한다고 한다.

하지만 토큰 기반 인증의 경우 직접 인증 방식을 저장하지 않으며, 클라이언트가 가지고 있기 때문에 세션 불일치 문제로부터 자유롭다고 한다. 토큰 기반 인증 방식의 경우 HTTP의 비상태성(Stateless)을 그대로 활용할 수 있으며, 높은 확장성을 가질 수 있다.

 

4. 서버의 부담

세션 기반 인증의 경우 서비스가 세션 데이터를 직접 저장하고 관리함.

따라서 세션 데이터의 양이 많아질수록 서버의 부담도 커진다.

토큰 기반 인증의 경우 클라이언트가 인증 데이터를 직접 가진다.

따라서 유저의 수가 얼마가 되었건간에 서버의 부담이 증가하지 않는다.

서버의 부담 측면에서는 세션 기반 인증 방식보다 토큰 기반 인증 방식이 유리하다.