[인증] 세션과 토큰 (Session and token for authentication)

---

#1. 개요

 

거의 모든 웹어플리케이션이 필수적으로 적용하는 기능이 회원과 로그인 입니다.
많은 프로젝트에서 User 관련 기능을 구현해보고, 세션 및 토큰 기반의 인증 방식을 모두 구현하거나 리팩토링한
적이 있음에도 불구하고, 방식에 대한 깊은 이해가 수반되지 않음을 반성하며 학습 내용을 포스팅합니다.

또한 염두해두지 않았던 토큰 방식(JWT)의 보안적인 문제와 HTTP header에 관해 별도의 포스팅으로 다룰
예정입니다.

 

---

#2. HTTP는 stateless 하다.

 

인증 방식에 대해 논하기 전에 stateless(무상태) 한 HTTP 특성에 대해 먼저 알아야합니다.
HTTP는 stateless한 프로토콜 입니다.

stateless 하다는 것은 서버가 클라이언트의 상태를 기억하지 않는다는 것입니다.

이러한 http의 특성때문에 클라이언트와 서버간의 요청 : 응답은 항상 독립적입니다.
즉, 클라이언트가 서버에 똑같은 데이터를 요청할때마다, 항상 동일한 방식으로 요청해야 합니다.

http가 stateless한 이유는 서버의 확장성(scaling) 때문입니다.
보통 여러대의 서버를 가지고 있는 서비스에서 어느 한 서버만 클라이언트의 상태를 저장하고 있다면
(즉, stateless하지 않다면) 요청을 처리해야 하는 다른 서버가 모든 서버를 돌면서 클라이언트의 정보를 찾아야 합니다.
이러한 서버간 정보공유에 대한 비용을 최소화하기 위해 http는 stateless 합니다.

 

다만 클라이언트의 정보를 저장하지 않는 이러한 http 특성때문에 모든 유저들은 서비스의 기능들을 사용할 때마다
로그인을 해야하는 번거로움을 경험해야 합니다.

이러한 문제를 해결하는 방법이 바로 세션과 토큰입니다.

---

#3. 세션과 토큰

 

Session(세션)

• 서버에서 각 브라우저(클라이언트)에 대한 독립적인 세션을 설정하고 서버에 저장
• 서버는 할당한 세션id를 클라이언트에게 전송
• 클라이언트는 브라우저 쿠키에 할당받은 세션 id를 저장
• HTTP 요청과정에서 헤더에 쿠키를 삽입하여 전송
• 브라우저가 전송한 쿠키의 세션id와 서버에 저장된 세션id를 비교 후 인증
  
  

Token(토큰)

• 서버는 클라이언트에 대한 토큰을 생성 및 전달하고, 클라이언트는 이를 브라우저에 저장 (로컬스토리지 혹은 쿠키)
  
• 로컬저장 -> XSS 공격에 매우 취약
• 쿠키저장 -> httpOnly, secure 옵션 등으로 XSS 공격 방어, 다만 CSRF 공격 위험 있음
• HTTP 요청과정에서 헤더에 토큰을 삽입하여 전송
• 브라우저가 전송한 token 정보를 서버가 가진 비밀키로 복호화하여 검증 및 인증

https://dev.to/vasilevskialeks/token-vs-session-authentication-56ed

---

#3. 세션과 토큰 차이점

 

 

	세션	토큰
확장성(Scalability)	서버에 세션을 저장하기 때문에 트래픽이 많아지면 서버 부담이 늘어난다. 이에 따른 서버 scale-out 또한 복잡해질 수 있다.	토큰은 클라이언트가 소유하고, 서버는 검증절차만 거치기 때문에 상대적으로 서버 부담이 적다.
안정성(Security)	하이재킹 등의 공격에 상대적으로 유리하다. 다만, 세션 자체가 탈취되면 문제가 커질 수 있다. 세션ID 자체에 유저 정보는 없지만, 세션에 접근할 수 있다.	브라우저에 저장하기 때문에 서버 차원의 보안이 불가능하다. (상대적으로 약하다.) 토큰이 탈취당하거나 문제가 생겨도 만료 전에 시스템(서버) 차원에서 강제하지 못한다.
사이즈(Size)	요청:응답 간 세션ID 자체는 상대적으로 작다.	요청:응답 간 토큰 사이즈는 상대적으로 크다

 

보통 토큰의 안정성 문제 때문에 만료 기간이 짧은 Acess token과 만료 기간기 길고 토큰의 재발급을 위한
Refresh token을 동시에 사용합니다. 
(refresh token은 특성상 매우 안전한 곳에 보관해야 하기 때문에 보통 데이터베이스에 저장하는 경우가 많습니다.)

토큰이 탈취당하거나 문제가 있는 경우 서버차원의 임시방편으로 검증에 필요한 비밀키를 변경하는 방법도 있습니다.
다만 이 경우 서비스를 이용하는 모든 유저가 다시 로그인을 하고 새로운 토큰을 발급받아야 합니다.

 

---

#4. 정리

 

• 인증 방식에는 세션과 토큰이 있으며, 이는 stateless한 http의 특성에 기인합니다.
• 세션과 토큰의 가장 큰 차이점은 세션은 서버에 토큰은 클라이언트에 저장한다는 것입니다.
• 세션과 토큰은 각각 장단점이 있지만 확장이 용이한 토큰이 어느 정도 규모 이상의 서비스에서 많이 쓰입니다.

---

#5. 참고

 

• [인증/인가]Session(세션)과 Token(토큰)(JWT)의 차이점 (https://fierycoding.tistory.com/69)
• 서버 기반 인증, 토큰 기반 인증 (https://dooopark.tistory.com/6)
• HTTP의 특징 (https://kotlinworld.com/97)
• Token vs Session (https://dev.to/vasilevskialeks/token-vs-session-authentication-56ed)

---