65.01_[Spring Security]JWT_Session 과 Token_22.11.23

>HTTP 프로토콜 특징

HTTP 프로토콜은 request를 전송한 후, response를 수신하면 연결을 끊는 비연결성(Connectionless)과 reques와 response에 대한 상태를 저장하지 않는 비상태성(Stateless)이 특징이다. 이는 다양한 장점을 갖게하는 특징들이지만, 사용자에게 불편을 가져다준다.

>세션 기반 자격 증명 방식

: 서버 측에 인증된 사용자의 정보를 세션(Session) 형태로 세션 저장소에 저장하는 방식

: Session은 서버측에는 세션 저장소에 저장되고, 클라이언트에는 쿠키로 저장된다. (클라이언트에는 세션 ID를 보낸다)

: 양측의 세션이 확인되면 인증된 사용자라고 판단하여 정보 교환을 한다.

>세션 기반 자격 증명의 특징

: HTTP 통신을 Stateful하게 사용할 수 있다.

: 세션은 서버 측 세션 저장소에서 관리하고, 그렇기 때문에 보안성 측면에서 유리한 점이 있다.

: 클라이언트의 쿠키 형태로 세션 ID를 저장하여 자격 증명을 확인한다.

: 세션 Id 만을 주고 받기 때문에 상대적으로 적은 네트워크 트래픽을 사용한다.

: 서버 측에 세션을 저장하기 때문에 서버를 확장할 때, 세션 불일치 문제가 생길 수 있다.

: 세션 데이터가 많아질 수록 서버에 부담이 가중된다.

: SSR 방식의 애플리케이션에 적합한 방식이다.

 

세션 기반 자격 증명 방식의 가장 큰 문제는 서버 확장에 불리하다는 것이다.
이를 보완하기 위해 Stick Session, Session Clustering, Session 저장소의 외부 분리 등의 노력이 있다.
간단히만 설명하면,

Stick Session : 세션 id를 포함한 요청을 보낼 때, 해당 세션 id를 저장한 서버에만 요청을 보낸다. 서버를 고정하기 위해서 쿠키나 IP tracking을 사용하는 것이 일반적이다.

Session Clustering : 여러 서버를 하나의 시스템처럼 사용하는 방식(Clustering)으로 단점을 극복한 것. 서버에 저장된 세션 정보를 모든 서버에 복사하는 형식의 방식이다.

Session 저장소의 외부 분리 : 아예 Session 저장만을 위한 서버를 구축하여 단점을 극복한 것이다.

충분한 보완이 되긴하지만 각각의 방식 또한 단점들도 있다.

 

>토큰

: 일반적으로 서비스를 이용하기 위한 자격이 된다는 것을 증명하는 일종의 확인증

 

>토큰 기반 자격 증명 방식

: 토큰 자체에 인증된 사용자 정보를 저장하는 방식

: 클라이언트의 request 헤더에 생성된 토큰을 포함시켜 인증된 사용자인지 확인함.

 

>토큰 기반 자격 증명 방식

: 인증된 사용자 정보를 토큰 자체에 저장하기 때문에 서버 측에서 별도의 관리를 하지 않음.

: 서버 측에서 별도의 관리를 하지 않기 때문에 서버의 확장성 면에서 유리하지만, 보안성이 떨어질 수 있다.

: 보안에 불리한 면이 있기 때문에 민감 정보는 토큰에 포함시키면 안된다. (토큰은 암호화가 되지 않기 때문에 토큰이 탈취

된다면 사용자 정보가 그대로 노출된다.)

: 인증된 사용자 정보 자체를 주고 받기 때문에 세션에 비해서는 많은 네트워크 트래픽을 사용한다.

: 토큰은 만료되기 전까지는 무효화 시킬 수 없다.

: 클라이언트와 서버가 좀 더 분리되기 때문에 상대적으로 Rest API 통신을 추구할 수 있고, CSR 방식의 애플리케이션에 적합하다.