쿠키,세션,토큰
[ HTTP는 Stateless Protocol ]
모바일 / 웹 서비스에 대부분 사용하는 HTTP는 무상태 프로토콜이다
--> 즉, 통신 이후에 어떠한 연결도 남지 않는다(stateless)
결과적으로, 사용자는 각각의 HTTP통신에 자신을 알릴 수 있는 정보를 주어야 한다
이 때, '자신을 알릴 수 있는 정보'의 역할을 하는 것이 바로 쿠키/세션/토큰 이다
쿠키(Cookie)
쿠키는 일종의 서버와 클라이언트가 대화하기 위한 수단.(클라이언트 로컬에 저장되는 'key-value'쌍의 데이터 파일)
[ 특징 ]
- 쿠키에 담긴 데이터는 브라우저에서 관리됨. (서버에서는 저장x)
- 사용자가 따로 처리 안해도 HTTP가 Request시 header에 자동으로 넣음
- Response header에 Set-Cookie 속성을 사용하면 쿠키를 만들 수 있음(서버가 쿠키를 만든후 브라우저로 보냄)
[ 구성요소 ]
- 이름 : 각각의 쿠키를 구별하는데 사용되는 이름
- 값 : 쿠키의 이름과 관련된 값
- 유효시간 : 쿠키의 유지시간
- 도메인 : 쿠키를 전송할 도메인
- 경로 : 쿠키를 전송할 요청 경로
[ 동작 방식 ]
1. 클라이언트가 HTTP Request 를 서버에게 보냄
2. 서버에서 유효성(회원인지)확인 후 쿠키를 생성한뒤 HTTP Response 헤더에 쿠키 넣어 응답
3. 클라이언트는 HTTP Response의 header에서 쿠키를 추출하여 저장
4. 클라이언트가 Request하고 싶을 때, HTTP가 해당 쿠키를 찾아 header에 자동으로 넣어서 전송
[ LifeCycle ]
- 쿠키 유효 시간이 만료되면 종료
- 브라우저 재시작 해도 종료되지 않음
- 유효시간 만료되도 클라이언트에 쌓임 (그래서 주기적으로 삭제 필요)
[ 사용 예시 ]
- 팝업창 다시보지 않기
- 아이디 / 비밀번호 저장
- 장바구니
---------------------------------------------------------------------------------------------------------------------------------
세션(Session)
쿠키를 매개로 사용한다, 사용자 정보 파일인 세션 ID를 서버에서 관리하는 방법(서버에서 저장하는 쿠키,세션쿠키)
서버와 클라이언트의 연결이 활성화된 상태
[ 특징 ]
- 클라이언트를 구분하기 위한 세션 ID를 발급
- 쿠키에 넣어서 보내기 때문에 쿠키를 수단으로 사용
- 브라우저가 종료되면 세션은 삭제
- 클라이언트 수 만큼 서버에 저장되기 때문에 서버 부하의 문제가 있음
[ 동작 방식 ]
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)의 한계
[ 서버 확장시 세션 정보의 동기화 문제 ]
서버가 여러개일 때, 각 서버마다 세션 정보가 저장 -> 서버1에 로그인 후, 새로고침 해서 서버2에 접근하면 인증 안됨
[ 서버 / 세션 저장소의 부하 ]
세션을 각 서버가 아닌 DB에 저장할 경우 -> 모든 요청에 DB조회로 인한 DB 부하!
[ 웹 / 앱 간 상이한 쿠키-세션 처리 로직 ]
기존의 Client는 브라우저가 유일했지만, 지금은 모바일이 존재 -> 웹 / 앱의 쿠키 처리 방법이 달라서 따로 처리해야함 !
---------------------------------------------------------------------------------------------------------------------------------
토큰(Token)
- 토큰은 서버의 상태를 저장하지 않음 (Stateless) -> 토큰 자체로 정보를 가지고 있어 별도의 인증 서버 필요 X
* 가장 많이 사용되는 JWT는 JSON 포맷으로 통신하여 범용성 있음 - 인증을 위해 사용되는 암호화된 문자열.
- 사용자가 인증에 성공하면 서버는 토큰을 생성해서 클라이언트로 보낸다.
- 토큰도 세션과 마찬가지로 사용자가 보내는 요청에 포함이 됨.
- 세션 인증에서는 서버가 세션 id를 저장하고 클라이언트가 쿠키에 실어 보낸 세션 id와 대조해서 확인하는 반면, 토큰을 사용하면 요청을 받은 서버는 토큰이 유효한지를 확인만 함.(http통신의 stateless 한 성격과 더 적합한 인증 방식)
- 세션 인증에 비해 서버 운영의 효율이 더 좋다.
- 쿠키 / 세션의 한계와 문제점 때문에 토큰이 등장하였음
Token에는 2가지가 있다
1) Access Token(접근을 위한 용도)
2) Refresh Token(Access Token이 만료되었을 때 갱신하는 용도)
[ Access Token ]
- 말 그대로 Access하기 위해 사용되는 Token !
- 우리가 흔히 말하는 Token은 이 Access Token을 의미
- 실제로 인증(Authorization)을 하기 위한 토큰 !
- 유효기간 15~30분
[Refresh Token]
- Access Token이 만료 되었을 때, 사용자가 다시 인증 과정을 거치지 않고 Access Token을 다시 받게 해주는 Token
- Refresh Token을 사용하면 서버에서 user별로 데이터를 유지해야 해서 user DB에 token필드를 만듬
- 당연히 Access Token보다는 만료 기간이 길다
- Refresh Token이 만료되면 다시 인증과정을 거처 발급 받아야 한다
- Refresh Token은 필수가 X
- Refresh Token은 Access Token보다 보안성이 매우 중요하다 -> 그래서 보안 문제로 굳이 Refresh Token을 사용 하지 않기도 한다
- 유효기간 2주