인증 방식 (Cookie & Session & Token)

서버가 클라이언트를 인증하는 방식은 대표적으로 쿠키, 세션, 토큰 3가지 방식이 있다.

각각의 특징에 대해서 간단하게 살펴보자.

 

1. Cookie (쿠키)

쿠키는 Key-Value 방식으로 저장되는 문자열이다. 클라이언트가 어떤 웹 사이트를 방문하면, 그 사이트에 연결되어 있는 서버를 통해 클라이언트의 브라우저에 저장되는 작은 기록 장치이다. 각각 사용자의 브라우저에 저장되니 고유 정보 식별이 가능한 것이다.

 

동작 순서

1. 브라우저(클라이언트)가 서버에 접속 요청

2. 서버는 클라이언트의 요청에 대한 응답을 작성하고, 응답 헤더에 클라이언트의 정보를 담아서 보낸다.

3. 이 후, 클라이언트는 서버에 요청을 보낼 때마다 저장된 쿠키를 요청 헤더에 담는다.

=> 서버는 쿠키에 담긴 정보를 바탕으로 클라이언트가 누군지 식별하고, 추천 광고를 띄우거나 한다.

 

단점

- 가장 큰 단점은 보안에 취약하다. 쿠키의 값을 그대로 전달하기 때문에 유출과 조작 위험이 있다.

- 용량 제한이 있어서 데이터 양이 한정적이다.

- 브라우저 간에 쿠키 지원 형식이 달라서 공유가 불가능하다.

- 쿠키의 사이즈가 커질수록 서버에 부하가 생긴다.

 

---

2. Sesstion (세션)

쿠키는 사용자의 정보를 브라우저(클라이언트)에 저장했다면, 세션은 클라이언트의 민감 정보를 서버 측에 저장한다. 서버의 메모리에 저장하거나, 로컬 파일 또는 데이터베이스에 저장한다. 핵심은 민감 정보는 서버에서 관리되어 유출 될 위험이 적다는 것이다. 

 

동작 순서

1. 유저가 웹 사이트에 로그인을 하면 세션이 서버 측에 메모리 또는 데이터베이스에 저장된다. (이 때, 세션을 식별하기 위해 Session ID를 기준으로 저장)

2. 서버에서 클라이언트에게 Session ID를 담은 쿠키를 전달한다.

3. 클라이언트는 모든 Request에 Session ID를 담아서 서버에 요청한다.

4. 서버는 받은 Session ID와 서버에 저장된 Session ID를 비교하여 인증을 한다.

 

단점

- 통신 중에 Session ID가 유출되더라도 민감 정보를 담고 있지 않아서 쿠키의 단점은 해결되었지만, Session ID를 탈취해 클라이언트인 척 정보를 요청할 수 있다. 

- 서버의 메모리가 사용되므로 요청이 많을수록 서버에 부하가 심해진다.

 

---

3. Token (토큰)

토큰은 임의로 생성된 비밀번호처럼 동작하고, 제한된 수명을 가지고 있는 것이 특징이다.

 

토큰 기반 인증 시스템은 클라이언트가 서버에서 접속을 하면 서버에서 해당 클라이언트에게 인증되었다는 의미로 '토큰'을 부여한다. 이 토큰은 유일하며 토큰을 발급받은 클라이언트는 서버에 요청할 때 헤더에 토큰을 담아서 보낸다. 서버는 받은 토큰과 서버에서 제공할 때의 토큰을 가지고 인증 절차를 거치게 된다.

 

동작 순서

1. 사용자가 서버에 로그인을 요청한다.

2. 서버에서 클라이언트에게 토큰을 발급해서 보내준다.

3. 클라이언트는 전달받은 토큰을 쿠키나 스토리지에 저장하고, 서버에 요청 시 헤더에 토큰을 담아 보낸다.

4. 서버는 전달받은 토큰을 가지고 인증 절차를 진행한다.

=> 토큰에는 요청한 사람의 정보가 담겨있기에, 서버가 DB를 조회하지 않고 클라이언트가 누군지 알 수 있다.

 

단점

- 데이터 자체의 길이가 길어서 인증 요청이 많아질수록 네트워크의 부하가 심해질 수 있다.

- payload 자체는 암호화되지 않아서, 중요한 데이터를 담지 않아야 한다.

- 중간에 유출되거나 탈취당하면 대처하기 어렵다. (제한 시간을 둬서 취약점 극복)