쿠키, 세션, 토큰에 관하여

처음 관련 자료를 접했을 때 쿠키와 세션은 독립적인 별개의 것이라고 생각했는데 그렇지 않았다. 애매하게 혼동되는 쿠키, 세션, 토큰의 개념을 한번 더 정리합니다. 

---

http 통신은 stateless 한 그 특징 때문에 사용자의 주고받은 개별 통신에 대한 정보를 저장하지 않는다.

때문에 같은 사용자가 여러 번 요청을 하더라도 그것을 알 수 없음.

따라서 사용자에 대한 상태를 파악할 수 없음. 이 것을 보완하기 위해 쿠키와 세션이 있음.

 

Cookie 

쿠키는 일종의 서버와 클라이언트가 대화하기 위한 수단.

• 브라우저가 서버와 연결이 되었을 때 브라우저에서 자동적으로 쿠키를 생성하고, response 할 때 쿠키를 담아서 보낸다.

• 특정 호스트에서 생성된 쿠키는 이후 모든 요청마다 서버로 전송됨

• 요청 해더의 set-cookie 속성에 정보를 담을 수 있음.

• 쿠키에 담긴 데이터는 브라우저에서 관리됨.

• 이름, 값, 만료 날짜, 경로 정보로 구성.

 

Session

서버와 클라이언트의 연결이 활성화된 상태.

• 클라이언트가 서버와 통신을 시작하면 서버는 해당 클라이언트에 대해 유일한 값인 세션 id를 부여, 세션 스토리지에 세션 정보를 저장함.

• 클라이언트는 이 세션id를 쿠키를 통해 기억함.

• 이후 클라이언트가 어떤 요청을 보낼 때마다 헤더의 cookie에 세션 id를 담아서 전송함.

• 서버는 클라이언트가 보낸 요청의 쿠키에 담긴 세션 id와 세션 스토리지에 담긴 세션 id를 대조해 인증 상태를 판단함.

  (즉, 세션과 쿠키는 완전히 분리된 개념이 아니며 세션은 쿠키를 기반으로 함)

• 각 클라이언트마다 유니크한 세션 객체가 주어지고, 이 세션 객체에 데이터를 담아 관리할 수 도 있음.

  (세션 객체가 자물쇠로 잠긴 상자라면 세션 id 가 열쇠인 셈)

• 세션을 사용하지 않고 쿠키만으로 어떤 데이터를 주고받는다면, 클라이언트는 이미 모든 데이터를 알고 있다는 것.

쿠키와 세션은 결국 사용자에게

1. 절절한 사용자 경험을 제공하고 ('일주일 간 다시 보지 않기', 로그인 유지하기 등)

2. 보안을 유지하기위해 사용된다.(인증 상태 관리)

 

Token

인증을 위해 사용되는 암호화된 문자열.

• 사용자가 인증에 성공하면 서버는 토큰을 생성해서 클라이언트로 보낸다.

• 토큰도 세션과 마찬가지로 사용자가 보내는 요청에 포함이 됨.

• 세션 인증에서는 서버가 세션 id를 저장하고 클라이언트가 쿠키에 실어 보낸 세션 id와 대조해서 확인하는 반면, 토큰을 사용하면 요청을 받은 서버는 토큰이 유효한지를 확인만 함. http통신의 stateless 한 성격과 더 적합한 인증 방식.

• 세션 인증에 비해 서버 운영의 효율이 더 좋다.

 

그렇다면 세션과 토큰 인증 어떤 게 더 나은 선택일까?

아직 경험이 없지만, 일반적으로 두 가지 모두 유효한 방법이라고 함.

웹사이트의 규모, 핸들링할 요청의 종류에 따라 선택할 수 있다고 하는데,

유저의 로그인 세션 정도만 인증이 필요한 작은 웹사이트에서는 세션 인증이 보통 좋은 선택이 될 수 있음.

하지만 규모가 큰 웹사이트라면 제이슨 웹 토큰(JWT)이 훨씬 나은 선택이 될 수 있다고 함.

레퍼런스 : https://dev.to/vasilevskialeks/token-vs-session-authentication-56ed

 

 

과제로 구현해 보면서 더 정확하게 개념을 체득해 보기로!