대엉코딩

0. HTTP의 특징

- 쿠키와 세션의 필요성을 알아보기 위해

   HTTP 프로토콜의 특징을 먼저 간단하게 파악해보겠습니다.

  0-1. Connectionless 프로토콜 (비연결지향)

     - 클라이언트가 요청(Request) 을 보내고, 서버가 응답(Response) 을 보낸 후 연결을 유지하지 않고 끊는 방식이다.

  0-2. Stateless 프로토콜 (상태정보 유지 안함)

     - 클라이언트의 상태 정보를 저장하지 않는 서버 처리 방식이다.

     - 그러나, 사용자의 편의를 고려하면 데이터 유지가 필요하다.

     - 로그인 상태 유지, 장바구니 내역 등 필요한 경우가 있다.

       ( stateful하게 사용해야할 때 쿠키와 세션을 사용한다. ) - 정보유지

- 이는 서버의 자원을 절약하기 위한 설정이라고 보면 되겠습니다. ( 비연결성 + 비상태성 )

1. 쿠키 와 세션

- 우선 표를 먼저 확인해보자

2. 쿠키( Cookie )

- 서버를 통해 인터넷 사용자의 컴퓨터에 설치되는 작은 기록 정보 파일

- 웹 사이트에 접속할 때 생성되는 정보를 담은 파일 ( 임시 파일 )

- 쿠키는 서버가 사용자의 웹 브라우저에 저장하는 데이터이다. ( 클라이언트 측에 저장 )

- 소프트웨어는 아니다. 단지 (key/value) 쌍의 string 형태이다. + ( 만료일, 경로 )

- 브라우저 간의 공유는 되지 않는다 ( 당연한가 )

- 아이디 저장 , 장바구니, " 더 이상 보지 않기"

- 저장 용량의 한계가 있다. ( 4KB, 총 300개, 도메인당 20개 )

- Session Cookie ( 브라우저 종료시 쿠키 삭제 ), Persistent Cookie ( 장기간, 브라우조 종료와 관계 x )

  Secure Cookie (HTTPS에서 사용, 쿠키 정보가 암호화되어 전송) 등 여러가지 종료가 있다.

  2.1 사용목적

    - 세션관리 ( 아이디, 장바구니 등 ) : 서버가 알아야할 정보들을 저장해놓는다.

    - 개인화 : 사용자마다 다르게 정보를 제공할 수 있다.

    - 트래킹 : 사용자의 행동을 기록하고 분석한다.

  2.2 단점

    - 쿠키에 대한 정보를 헤더에 매번 담아보내야하므로, 오버헤드가 발생한다.

    - 쿠키의 정보가 유출되는 보안에 취약한 문제점이 있다. (클라이언트 측에 저장되므로)

    - 쿠키를 거부하도록 설정할 수 있지만, 사용에 있어 불편함을 느낄 수 있다.

3. 세션( Session )

 - 쿠키 기반이며, 동작원리도 비슷합니다.

 - 클라이언트가 요청을 보내면, 서버는 헤더를 보고 session-id를 보냈는지 확인한다.

 - 존재하지 않으면, 서버는 세션 ID를 생성해 클라이언트에게 돌려주고, 클라이언트는 이를 사용해 서버에 저장한다.

 - 세션 ID가 1개씩 생성되어 웹 컨테이너에 저장된다.

 - 클라이언트 측이 아닌 서버측에 저장한다.

 - 이로인해, 많은 요청이 일어날 경우 서버에 과부화를 줄 수 있습니다.

 - 서버리소스를 초과하지 않는 함 상대적으로 용량의 한계가 없는 편

 - 서버 측에 저장하기 때문에 보안적인 측면에서 유리하다. (서버 측에서 관리)

 3.1 사용목적

    - 쿠키와 크게 다르지 않다.

 3.2 단점

    - 서버에 과부화를 줄 수 있다.

    - 쿠키보다 속도가 느리다. 서버에서 추가적인 처리가 필요하기 때문

4. 쿠키와 세션의 차이점

  - 가장 큰 차이점은 저장위치 ( 클라이언트(쿠키), 서버(세션) )

  - 그에 따른 보안과 속도의 차이 ( 위의 표에 적혀 있음 )

  - 라이프 사이클 (만료기간) 관점에서 쿠키는 만료기간 설정에 따라 넉넉하게 잡으면 오래 유지가 가능하다.

     반면 세션은 만료시간을 정해두어도 브라우저가 종료되면 만료시간에 상관없이 삭제된다.

  - 보안과 성능의 관점에서 저장할 정보들을 보고 적절하게 두가지를 잘 사용할 필요가 있겠습니다.

로그인을 구현하기 위한 방법 중 

session기반(서버)의 인증 방식

-> 클라이언트와 서버 간의 상태를 유지하기 위해 사용하는 방식

-> 단점으로 유저의 수가 늘어난다면 무리가 갈 수 있고, 데이터베이스의 성능에 저하를 줄 수 있다.

-> 확장성에 있어서 문제가 생길 수 있다. (비용이 많이 듬 , 쉽지 않음)

-> 확장을 위해 분산된 시스템을 설계할 경우 과정이 매우 복잡해 질 수 있다.

토큰(token) 기반 시스템의 방식

-> 오늘 주요하게 살펴볼 토큰 기반 방식 입낟.

-> stateless 

     - 토큰 방식에서는 유저의 인증 정보를 서버(세션) 에 담아놓지 않는다.

     - 이를 통해 서버를 이용할 때의 문제점을 많은 부분 해소가 가능하다.

 -> 1. 사용자가 id와 pw 로 로그인을 한다.

 -> 2. 서버는 이 정보를 검증한다.

 -> 3. 가지고 있는 계정정보와 입력된 정보가 정확하다면 유저에게 signed된 토큰을 발급해준다.(정상발급)

 -> 4. 유저측은 전달받은 토큰을 저장해두고, 로그인된 상태에서 접근가능 한 정보에대해 서버에 요청을 할 떄

        해당 토큰을 함께 서버에 전달을 한다. (헤더)

 -> 5. 서버는 토큰의 검증 과정을 포함하여, 주어진 요청을 처리하여 준다.

-> 로그인 정보가 여러 곳에서 사용가능 하다 . 발급 받은 토큰을 가지고 다른 시스템에 접근이 가능하도록

    설계할 수 있으며, 토큰에 선택적인 권한을 주어 발급을 할 수도 있다.

-> JWT의 경우 웹 표준 RFC 7519에 등록되어 있으므로 여러 환경에서 지원이 되며, 다방면으로 사용되고 있다.

-> 권한유효성을 검사 할 때 데이터베이스에 접근하지 않아도 된다는 장점이 있다.

    로그인한 사용자인지 확인을 할 때, 토큰의 유효 여부만 확인을 하면 된다. (데이터베이스 접근을 줄임)

-> 보안의 문제는 IP주소에대한 추가 검증등 을 통해 보완할 수는 있으나 여전히 보안 문제는 JWT를 사용시 일어날 수      있는 문제이다.

간단하게

장점 

-> 데이터베이스 접근을 최소화 할 수 있다.

-> 간편하다.

단점

-> 다른 글에서도 언급했듯 보안문제는 보완, 해결해 나가야할 과제이다.

-> 프론트엔드 측에서 토큰을 관리 해야 한다는 것