Session과 Cookie

안녕하십니까, 오블완 이모티콘을 받은 웅쓰입니다.

이모티콘을 받은 기념으로 평소 이해를 잘 못하고 넘어갔던 Session과 Cookie의 쓰임새에 대해 정리해 보려고 합니다.

해당 글은 개념 보단 실제 어떻게 사용되고 있는지에 대해서 정리를 하는 글이니 참고 바랍니다.

날이 추우니 후딱 정리하고 집에 가서 쉬겠습니다.

 

 

목차

• 머릿말(나는 바보였다.)
• Session
• Cookie

 

머릿말(나는 바보였다.)

- 필자는 바보다. 필자는 항상 Session과 Cookie는 뭔가 상반되는 쓰임새를 가지고 있다고 생각했다. 왜 그렇게 생각했을까?를 되뇌어보니 Session은 보안적인 측면이 우수하고 서버에 저장되는 반면, Cookie는 보안이 좋지 않고 클라이언트쪽에 저장된다는 개념 때문에 그런 생각을 했던 것 같다... 하지만 실무에서 접해보니 둘은 상반된 쓰임새가 아니라 둘이 힘을 모아 로그인 시 안전하게 클라이언트 정보를 일정 기간 동안 유지하며 지켜주고 있었던 것이었다..

 

1. Session

- Session은 위에서 언급했듯이 서버에 클라이언트 정보를 저장하는 방식이다. 클라이언트가 로그인을 하면 로그인 정보를 서버에 저장해 외부로부터 안전하게 유지할 수 있다. Session 방식의 흐름을 정리해보면

 

       1) 사용자가 웹 서버에 요청을 보냄

       2) 서버는 사용자를 식별하기 위해 고유한 SessionID를 생성

       3) SessionID는 브라우저에 Cookie로 저장되거나 URL 쿼리 스트링으로 전달

       4) 클라이언트가 다음 요청을 보낼 때, Session ID를 서버로 보내 사용자를 식별

       5) 서버는 Session ID를 기반으로 저장된 사용자 데이터를 참조해 요청을 처리

 

3번이 보이나? 그렇다. 보안상 안전한 Session 방식을 가지고 클라이언트와 소통하기 위한 방법 중 하나가 Cookie를 사용한 것이다.

 

2. Cookie

- 클라이언트가 로그인을 하면 로그인 정보를 Session 방식으로 저장 -> Session은 서버에 저장되는 것이니 클라이언트에겐 서버가 클라이언트를 식별할 수 있게 해주는 Session ID를 전달하는 흐름을 파악했다. 그리고 위 Session 흐름에서 Session ID를 브라우저의 Cookie로 저장하거나 URL 쿼리 스트링으로 전달한다고 했다.

 

우선 URL 쿼리 스트링은 보안상 취약하니 배제해야 한다. 쿼리 스트링으로 전달한다는 것은 예를 들어, 네이버 로그인 시 www.naver.com?session_id=3fj3ifjwiofjsef 이렇게 URL로 전달한다는 것인데 아무리 로그인 정보가 아니라 식별자 역할인 session_id라 하더라도 저렇게 공개적인 URL로 들어내면 보안에 취약해진다. 그러므로 배제!     

 

그럼 SessionID를 클라이언트에게 전달하기 위해서는 Cookie를 사용해야 할 수 밖에 없다!!

 

그래서 필자는 다소 미시적인 관점으로 생각했을 때 Cookie는 사용자가 로그인을 한 이후 SessionID를 부여 받을 때 서버 -> 클라이언트로 SessionID를 전달해주는 매개체라고 정리를 했다.

 

물론! Cookie가 SessionID 뿐만 아니라 다양한 데이터를 저장하고, 또 다양한 용도로 사용될 수 있다. 그럼에도 불구하고 이렇게 로그인 플로우를 통해서 Cookie의 역할을 정리하면 추후에 Cookie가 다른 곳에서 쓰일 때도 어떤 느낌으로 사용될지 기초 구성은 바로 생각해낼 수 있을 것 같아서 정리해 보았다.

 

session과 cookie에 대해서 추후에는 직접 테스트도 해보고!! 관련 코드들도 사용해보며 조금 더 수준높은 글을 작성해 보겠습니다...! 꾸준히 성장해 나아가겠습니다!! 화이팅!!