201029_TIL

TODAY I LEARNED

• 쿠키
• 세션
• 토큰

@@ 오늘은 쿠키, 세션, 토큰에 대해서 알아봤다. 쿠키와 세션의 차이점은 어디에서 저장되고 관리되는가 이다.
어제 오피스 아워 진행하다보니 세션과 쿠키의 개념 차이는 있지만 정확히 딱 분리할 수 없는게 세션도 쿠키를 이용하고, 또 블로깅을 찾아보니 쿠키에서도 종류가 지속 쿠키와 세션쿠키로 나눠지는 것을 보니 헷갈리는 지점들이 많았다.

쿠키는 어쨌든 클라이언트에 저장되고(브라우저 혹은 파일형태로) 세션은 서버에서 관리가 된다.
쿠키 중에서도 Max-Age와 같은 옵션값을 설정한 쿠키는 지속 쿠키로 파일에 저장되어 기간이 만료되면 삭제되지만, 세션쿠키는 브라우저가 종료되면 사라진다. (다만 크롬 같은 브라우저 고급 설정에서 백그라운드 실행, 시작하는 위치등이 설정돼있을 경우 세션쿠키더라도 삭제가 되지 않을 수 있다).

쿠키는 그래도 명확히 알겠는데, 세션은 더 어렵게 느껴진다. 세션은 서버에서 관리를 하는데 쿠키를 통해 세션 아이디를 넘겨줘서 인증하는 나름 고전적인 방법을 배웠고, 토큰의 개념까지 더해지면서 그래서 도대체 어떠한 형태로 DB에 있는 비밀번호는 저장이 되고(배울 땐 해싱된 비밀번호 형태로 배웠다) 이는 서버에서 어떤 형식으로 관리되고 저장되는가, 세션값은 브라우저 종료시 삭제 되는데 자동 로그인은 또 어떠한 형태로 지속이 되는 건지 등이 궁금하다. (이것은 좀 더 찾아봐야 할 거 같다)

또 어제 헷갈렸던 개념이 토큰 인증 방식이다. 설명을 들으며 비밀번호 해싱과 토큰은 다른 것인데 자꾸 해싱 비밀번호와 토큰이 같다고 생각하여 혼돈이 왔다. crypto 같은 모듈을 이용하여 비밀번호를 해싱하고 , 해싱된 값을 회원가입시 DB에 저장한다. (이것은 토큰인증방식과는 다른 결이다)
이런 뒤 로그인할 때 만약 로그인에 성공하면, 토큰을 생성해서 (jwt 와같은 모듈을 사용하여) 클라이언트에게 전달해주고, 그것을 클라이언트는 요청할때마다 요청 헤더에 토큰을 넣어서 요청하는 것이다.
그럼 서버는 토큰이 정상적인지만 확인을 하고, 해당 요청에 대한 데이터 값을 응답해주게 된다.

일단 내가 이해하기로는 이 정도까지 왔다. 아래 제로초님과 벨로퍼트님 글을 읽으면서 다시 정리가 됐는데, 특히 벨로퍼트님 글을 읽으니 왜 토큰 인증 방식을 사용하게 됐는지 사용자가 많아지면서 세션으로 인한 서버의 과부하가 탄생 배경이라는 사실을 알게 됐다. 왜 쓰게 됐는지, 왜 필요한지를 아는 게 무언가를 배울 땐 꼭 필요한 부분인 것 같다. 덕분에 이해가 더 쉽게 되었다.

crypto 설명, 제로초 블로그 글 : 참조
jwt,토큰인증에 관한 글, 벨로퍼트 : 참조

쿠키와 세션은 왜 사용하는가

• 데이터 유지를 위하여

  데이터가 유지되지 않는 다면 매번 페이지 이동 시 로그인을 다시하거나 해야 하는 일이 발생한다.

  서버와 클라이언트가 통신 할 때 통신이 연속적으로 이어지지 않는다.(stateless)

• http 통신은 매번 독립적으로 이루어진다. 개별 통신에 대한 정보를 저장하여 기억해두지 않는다.

• 쿠키와 세션을 활용하면 여러번의 통신에 걸쳐 어떤 사용자에 대한 상태를 파악할 수 있다.

쿠키와 세션의 차이

쿠키

• 서버와 클라이언트가 대화하기 위한 수단
• 사용자가 사이트에 접속시, 서버가 사용자의 컴퓨너에 저장하는 클라이언트에 저장되는 키와 값이 들어있는 작은 파일이다.
• 서버에서 응답 헤더에 Set-Cookie 속성을 이용하여 제공한다.
• 쿠키는 클라이언트 상태 정보를 로컬에 저장했다가 요청할 때 참조.
• 세션 쿠키, 지속 쿠키
  • 만료 날짜/시간을 지정하지 않으면 세션 쿠키로 저장.
  • 만료일이 되면 디스크에서 쿠키가 제거된다.
  • 지속 쿠키의 경우 보안에 취약하다.
  • 세션 쿠키는 브라우저에 저장. 브라우저가 종료되면 사라진다.
    • 그러나 크롬에서 고급 설정 > 백그라운드에서도 크롬이 동작하게 되어있거나, 브라우저 시작시 종료된 브라우저에서 시작하도록 설정되어있을 경우엔 브라우저를 다 종료해도 세션 쿠키가 남아있는 것을 확인할 수 있다.
  • 지속 쿠키의 경우 파일로 저장된다.
• 쿠키는 별도로 요청하지 않아도 브라우저에서 서버에 요청 시 요청 헤더값에 쿠키 값을 넣어 요청한다.
• 저장한 도메인에서 요청할 때만 쿠키값이 제공된다.
• 클라이언트에서 최대 300개까지 쿠키를 저장할 수 있다. (하나의 도메인 당 20개의 쿠키) 하나의 쿠키는 4KB까지 저장 가능하다.
• 클라이언트가 요청한 웹페이지를 응답으로 받으며 서버에서 받는 쿠키값을 응답으로 받고 저장한다.
• 쿠키 사용 사례
  • 오늘 하루 더이상 보지 않기 등 팝업 관리

세션

• 서버에 클라이언트 상태 정보를 저장하는 기술, 논리적인 연결.
• 서버와 클라이언트가 연결되어있는 상태. 세션 활성화가 시작되면 해당 클라이언트에 대해 유일한 아이디(세션id) 부여
• 세션 스토리지에 세션에 대한 정보를 저장.
• 클라이언트는 이 세션 id를 쿠키를 통해 기억한다.
• 어떤 요청을 보낼 때마다 헤더의 쿠키에 세션 id를 담아 전송한다. 서버는 클라이언트가 보낸 요청의 쿠키에 담긴 session id와 세션 스토리지에 저장된 세션 id 를 대조하여 인증 상태를 판단. (세션 또한 쿠키를 기반으로 한다)
• 각 클라이언트마다 유니크한 세션 객체가 주어진다.
• 세션 객체에 어떤 데이터를 담아서 관리할 수도 있다. (세션 객체와 데이터는 서버에 존재)
• 세션 객체는 서버에 있기 때문에 자물쇠로 잠긴 상자. 세션 id를 통해서 열수 있다.
• 그러나 쿠키는 클라이언트에 다 드러나는 정보이다.
• 세션은 서버 자원을 사용.
• 사용자가 많을 경우 소모되는 서버의 자원이 상당하기 때문에 쿠키와 세션을 적절하게 섞어 사용하여 자원 낭비를 방지해야 한다.

보안

• 쿠키는 보안이 취약하나 세션은 클라이언트 정보 자체가 서버에 저장되어 있으므로 비교적 안전하다
• 쿠키는 브라우저를 종료하더라도 저장되어 있을 수 있고, 세션은 서버에서 만료시간/날짜를 정해서 지워버리거나 세션 쿠키에 세션 아이디를 정할 경우 브라우저 종료시 세션 아이디가 날아갈 수 있다.

속도

• 쿠키가 세션보다 속도 면에서 유리

출처 : 자세한 내용은 여기

토큰

• 인증을 위해 사용되는 암호화된 문자열
• 토큰 또한 세션과 마찬가지로 사용자가 보내는 요청에 포함된다.
• 서버는 토큰이 유효한지 확인한다.
• 세션 인증, 서버가 세션 아이디를 저장하고 클라이언트가 쿠키에 실어 보낸 세션 id가 세션 스토리지에 저장되는 과정이 없다. (서버 운영의 효율 측면으로 더 좋다)

세션 인증방식 과 토큰 인증 방식(JWT)

세션 관리의 취약점

• 세션 아이디 훔치기( 패킷 스니핑 ), 가로채는 것이 가능하다
• 세션 아이디 생성 방법이 부적절할 경우 세션 하이재킹(추측)이 가능하다.
• 공격자가 사용자의 브라우저에 세션 id를 설정하여 세션 하이재킹이 가능하다.

*하이재킹: 선박 납치라는 뜻의 하이재킹으로, 시스템에 접근할 적법한 사용자 아이디와 패스워드를 모를 경우 공격 대상이 이미 시스템에 접속되어 세션이 연결되어있는 상태를 가로채기 하는 공격. 아이디와 패스워드를 몰라도 시스템에 접근하여 자원이나 데이터를 사용할 수 있는 공격.