💡 쿠키와 세션

세션 기반 & 토큰 기반 자격 증명

HTTP 프로토콜은 무상태성(Stateless)으로 인해 클라이언트의 Request에 대한 서버의 Response를 수신하게 되면 연결을 끊는 비연결성(Connectionless)의 특징을 가진다.

클라이언트가 로그인 인증을 위해 요청을 보내더라도 무상태성때문에 로그인의 상태가 유지되지 않는다. 이러한 단점을 보안하기 위해 쿠키와 세션을 사용한다고 학습했다.

세션 기반 자격 증명

세션은 클라이언트의 Request에 자동으로 서버에 전달되는 쿠키에 세션 Id가 담겨 전달되는 방식으로 사용되지만 브라우저에 저장되는 쿠키와는 달리 서버에서 관리된다.

이 말은 인증된 사용자의 정보를 서버의 세션 저장소에서 관리하고 클라이언트에겐 해당 사용자를 구분할세션 Id만 전달하는 것이다.

☝️즉, 세션 기반 자격 증명 방식이란 서버 측에 인증된 사용자의 정보를 세션 형태로 세션 저장소에 저장하는 방식임을 알 수 있다.

세션 기반 자격 증명의 특징

• 인증된 사용자의 정보를 서버의 세션 저장소에서 관리
• 서버로부터 생성된 세션ID는 고유한 값을 가지며, 클라이언트의 쿠키에 저장되어 있다가 resquest시 쿠키가 전송되는 시점에 함께 전송되며 인증된 사용자임을 증명하는 수단으로 사용된다.
• 세션ID만 클라이언트 쪽에서 사용하므로 상대적으로 적은 네트워크 트래픽을 사용
• 서버에서 세션 정보를 관리하므로 보안성 측면에서 조금 더 유리
• 서버의 확장성 면에서는 세션 불일치 문제가 발생할 가능성이 높다.

🧐
하나의 서버를 사용할 때에는 문제가 없지만 서버가 여러개로 확장되었을 때 HTTP 요청을 받는 서버를 지정해 요청을 보낼 수 없다.
만약 내가 보낸 요청을 받은 서버의 세션 저장소에 나의 정보가 담겨져 있지 않다면 세션 불일치 문제가 발생하는 것!
☝️ 세션 불일치 문제는 외부 저장소로 분리하는 작업 등을 통해 보완한다.

• 세션 데이터가 많아질수록 서버의 부담이 가중된다.
• SSR 방식의 애플리케이션에 적합한 방식

토큰 기반 자격 증명 방식🪙

토큰🪙(Token)

버스 토큰도 안써봤는디..

비용을 지불하면 받을 수 있는 토큰은 이미 비용을 지불했기 때문에 사용에 대한 권한을 가진 것이다.

☝️이처럼 애플리케이션 보안 측면에서의 토큰은 사용자의 자격 증명 정보가 포함되어 있다고 생각하자.

서버에 세션 정보(사용자 증명 정보)를 저장해놓고, 클라이언트의 요청을 할 때마다 세션 ID를 서버에 보내 사용자의 상태를 유지하는 세션 기반 자격 증명 방식과는 달리 토큰 기반 자격 증명 방식은 클라이언트의 요청 시마다 사용자의 자격 증명 정보를 보내는 것이다.

토큰 기반 자격 증명 방식의 특징

• 토큰에 인증된 사용자 정보를 저장하기 때문에 서버에서 별도의 관리를 하지 않는다.
• 생성된 토큰은 클라이언트의 Request를 보낼 때, header에 포함되어 사용자를 증명하는 수단으로 사용된다.
• Request마다 사용자 정보가 저장된 토큰을 보내야하므로 세션에 비해 더 많은 네트워크 트래픽을 사용한다.
• 서버에서 토큰을 관리하지 않기 때문에 보안성 측면에서 조금 더 불리하다.
• 사용자의 인증된 정보를 서버에서 관리하지 않기 때문에 서버의 확상성 면에서 유리하고 세션 불일치와 같은 문제가 발생하지 않는다.
• 기본적으로 토큰이 만료되기 전까지는 토큰을 무효화 시킬 수 없다.
• CSR 방식의 애플리케이션에 적합한 방식

🧐단, 토큰에 저장된 사용자 정보는 토큰의 특성 상 암호화가 되지 않기 때문에 탈취될 위험이 크다. 따라서 민감한 정보를 포함시키지 않도록 주의해야 한다.
☝️ 토큰의 무효화 문제는 토큰의 만료기간은 짧게 설정해 보완한다.