NodeJS - 인증(쿠키, 세션, 토큰)

김정욱·2020년 12월 10일
8

NodeJS

목록 보기
8/22

인증이 필요한 이유

[ HTTP는 Stateless Protocol ]

: 모바일 / 웹 서비스에 대부분 사용하는 HTTP는 무상태 프로토콜이다
      --> 즉, 통신 이후에 어떠한 연결도 남지 않는다
결과적으로, 사용자는 각각의 HTTP통신에 자신을 알릴 수 있는 정보를 주어야 한다
이 때, '자신을 알릴 수 있는 정보'역할을 하는 것이 바로 쿠키/세션/토큰 이다

인증 수단

크게 인증을 하는 방법은 4가지가 있다
1) 요청 내용에 비밀번호를 넣는 방법
: 항상 요청할 때 정해진 비밀번호를 넣는다 -> https를 해도 보안에 매우 취약!
   (실제로 안쓰임)
2) 쿠키(Cookie)
3) 세션(Session)
4) 토큰(Token)

쿠키(Cookie)

: 클라이언트(브라우저 or 디바이스) 로컬에 저장되는 'key-value'쌍의 데이터 파일


[ 특징 ]

  • 쿠키 유효시간을 명시 가능 / 브라우저가 종료되어도 유지
  • 클라이언트에 저장했다가 참조
  • 최대 300개 / 하나의 도메인당 20개 까지 / 하나의 쿠키는 4KB까지 가능
  • Response header에 Set-Cookie 속성을 사용하면 쿠키를 만들 수 있음
  • 사용자가 따로 처리 안해도 HTTP가 Request시 header에 자동으로 넣음

[ 구성요소 ]

1) 이름 : 각각의 쿠키를 구별하는데 사용되는 이름
2) 값 : 쿠키의 이름과 관련된 값
3) 유효시간 : 쿠키의 유지시간
4) 도메인 : 쿠키를 전송할 도메인
5) 경로 : 쿠키를 전송할 요청 경로


[ 동작 방식 ]

(출처 : https://doooyeon.github.io/2018/09/10/cookie-and-session.html)

1. 클라이언트가 HTTP Request 를 서버에게 보냄

2. 서버에서 유효성(회원인지)확인 후 쿠키를 생성
     & HTTP Response 헤더에 쿠키 넣어 응답

3. 클라이언트는 HTTP Response의 header에서 쿠키를 추출하여 저장

4. 클라이언트가 Request하고 싶을 때, HTTP가 해당 쿠키를 찾아 header에 자동으로 넣어서 전송


[ LifeCycle ]

  • 쿠키 유효 시간이 만료되면 종료
  • 브라우저 재시작 해도 종료되지 않음
  • 유효시간 만료되도 클라이언트에 쌓임 (그래서 주기적으로 삭제 필요!)

[ 사용 예시 ]

  • 팝업창 다시보지 않기
  • 아이디 / 비밀번호 저장
  • 장바구니

세션(Session)

: 쿠키를 매개로 하지만, 사용자 정보 파일인 세션 ID를 서버에서 관리하는 방법


[ 특징 ]

  • 클라이언트를 구분하기 위한 세션 ID를 발급
  • 쿠키에 넣어서 보내기 때문에 쿠키를 사용하지 않는것은 아님
  • 브라우저가 종료되면 세션은 삭제
  • 클라이언트 수 만큼 서버에 저장되기 때문에 서버 부하의 문제가 있음

[ 동작 방식 ]

(출처 : https://doooyeon.github.io/2018/09/10/cookie-and-session.html)

1. 클라이언트 HTTP Request를 서버에게 보냄

2. 서버에서 유효성(회원인지)확인 후 / 고유한 Session-ID를 발급하여 쿠키에 넣음
 & HTTP Response header에 넣어 응답

3. 클라이언트는 HTTP Response header에서 이 쿠키를 추출하여 저장

4. 클라이언트가 HTTP Request를 보낼 때, HTTP가 해당 쿠키를 찾아 header에 자동으로 넣어서 전송

5. 서버는 HTTP Request header에서 쿠키안에 Session-ID를 확인하고 통신!


[ LifeCycle ]

  • 세션 유효시간이 만료되면 종료
  • 브라우저가 종료되면 삭제됨

[ 사용 예시 ]

  • 로그인

쿠키 / 세션 차이점

  • 저장위치
    • 쿠키 : 클라이언트(브라우저 or 디바이스)
    • 세션 : 서버
  • 보안
    • 쿠키 : 클라이언트에 저장되므로 보안에 매우 취약
    • 세션 : 쿠키 내부에 Session-ID만 있기에, 직접적인 정보노출은 없다
                그리고 서버에서 관리하므로 쿠키보다 비교적 보안성이 좋다
  • LifeCycle
    • 쿠키 : 만료시간 / 만료시간이 없다면 브라우저 종료해도 남아있음
    • 세션 : 만료시간 / 브라우저 종료시 무조건 삭제
  • 속도
    • 쿠키 : 클라이언트에 저장되어 있어서 서버 요청시 빠름
    • 세션 : 실제 저장된 정보가 있으므로 서버의 처리가 필요해 쿠키보다 느림

세션(Session)의 한계

(ref : https://m.blog.naver.com/PostView.nhn?blogId=ithink3366&logNo=221366364878&proxyReferer=https:%2F%2Fwww.google.com%2F)


[ 서버 확장세션 정보의 동기화 문제 ]

: 서버가 여러개일 때, 각 서버마다 세션 정보가 저장
     --> 서버1에 로그인 후, 새로고침 해서 서버2에 접근하면 인증 안됨!


[ 서버 / 세션 저장소의 부하 ]

: 세션을 각 서버가 아닌 DB에 저장할 경우
    --> 모든 요청에 DB조회로 인한 DB 부하!


[ 웹 / 앱 간 상이한 쿠키-세션 처리 로직 ]

: 기존의 Client는 브라우저가 유일했지만, 지금은 모바일이 존재
     --> 웹 / 앱의 쿠키 처리 방법이 달라서 따로 처리해야함 !


[ 해결방법 ]

Token 사용 ! (Self-contained & Stateless)

토큰(Token)

  • 쿠키 / 세션의 한계와 문제점 때문에 토큰이 등장하였음
  • 토큰은 서버의 상태를 저장하지 않음 (Stateless)
    --> 토큰 자체로 정보를 가지고 있어 별도의 인증 서버 필요 X
    * 가장 많이 사용되는 JWT는 JSON 포맷으로 통신하여 범용성 있음
  • token을 사용하는 과정
    (ref : https://dunkey2615.tistory.com/119)

Token과 관련한 글은 다음에 계속 !

(Access Token / Refresh Token)

글 작성 References

https://doooyeon.github.io/2018/09/10/cookie-and-session.html

https://interconnection.tistory.com/74

https://tansfil.tistory.com/58

https://chrisjune-13837.medium.com/web-%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98%EC%9D%B4%EB%9E%80-aa6bcb327582

profile
Developer & PhotoGrapher

0개의 댓글