인증이 필요한 이유
[ 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)의 한계
[ 서버 확장시 세션 정보의 동기화 문제 ]
: 서버가 여러개일 때, 각 서버마다 세션 정보가 저장
--> 서버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
