Session vs Token(JWT)

HTTP는 Stateless (비 상태 유지) 한 특징을 가진다. 서버가 클라이언트의 연결을 유지하지 않는다는 의미이다.

그래서 세션/토큰 방식을 사용하지 않고 로그인을 진행할 때는 url 이동 시마다 로그인을 해야 하는 현상이 발생한다. 

 

이것 때문에 처음 로그인을 구현할 때 어떻게 하지? 하고 난감해했던 기억이 있다.

지금은 그다지 어렵지 않게 구현할 수 있지만, 각각의 정의와 장단점을 한번 정리해 보았다

---

Authentication(인증)

사용자의 신원을 확인하는 과정

 

Authentization(인가)

인증된 사용자에게 접근 권한을 부여하는 것

 

 

세션 기반 인증

 

JSON 웹 토큰이 등장하기 전에 주로 사용한 유형. 서버에 저장되므로 관리자가 세션에 대한 권한을 갖는다.

그러므로 사용자가 보낸 세션ID를 조회하는 역할을 한다.

 

1. 사용자 로그인
2. 서버: 사용자를 위한 세션 생성, 세션 데이터 서버를 메모리에 저장
3. 클라이언트: 사용자 요청 시 마다 세션 ID가 저장된 쿠키를 전송
4. 서버: 처음 로그인 시 저장한 세션 데이터로 전송된 쿠키의 세션 데이터 비교 후 verification(유효성 검증) 및 Authorization(인가)을 통해 Response를 보냄

사용자 로그아웃 시 해당 세션 데이터가 DB와 서버 메모리에서 삭제

 

 

장점

• 강제 로그아웃, 접속인원 제한, 로그인된 디바이스 확인 등 로그인과 관련된 방면으로 활용 가능

 

단점

• 사용자가 늘어남에 따라 세션 ID를 저장할 공간도 더 확보해야 한다.
• 사이트 간 요청 위조 공격에 노출될 수 있고, 공격자가 세션 ID를 가로채서 서버에 유해한 요청을 수행할 가능성이 있다.

 

---

토큰 기반 인증

 

JWT(JSON 웹 토큰)을 사용한다. RESTful API에 널리 사용되는 방법

 

1. 사용자 로그인
2. 서버: JWT(JSON Web Token) 형태의 암호화된 토큰 생성 후 클라이언트로 보냄
3. 클라이언트: 활동을 수행할 때 해당 사용자의 고유 키로 토큰을 전송
4. 서버: 모든 요청에 대해 JWT가 해당 사용자인지 확인하고 Response를 다시 클라이언트로 보냄

 

 

장점

• 이미 권한 정보를 갖고 있기 때문에 별도 조회 시간, 리소스를 절약할 수 있다
• 구현이 비교적 쉽다

 

단점

• 인증 내용이 클라이언트에 저장되기 때문에 특정 보안 작업 수행 불가
• 유효한 토큰을 탈취당할 시 서버 접근이 가능하게 됨

 

 

어떻게 적재적소에 쓰면 좋을까?

• 먼저 사용자 수를 예측해보아야 한다. 세션은 상대적으로 서버에 부담을 주기에 동시 접속 사용자수에 맞춰 적절한 설계를 해야 한다.
• 로그인 유지와 같은 간단한 정보는 쿠키를 통해 서버 부담을 덜어낸다
• 보안적으로 숨겨야 할 부분이 생긴다면 세션을 사용한다
• 강제 로그아웃(은행 등) 같은 기능을 고려한다면 세션을 사용해야 한다

 

 

 

 

 

reference

https://hackernoon.com/using-session-cookies-vs-jwt-for-authentication-sd2v3vci

https://kdhyo98.tistory.com/92

https://cs-vegemeal.tistory.com/77