1. 쿠키란 무엇일까?
1 - 1) 쿠키는 브라우저에 키와 값의 형태로 저장되는 작은 데이터 파일이다.
1 - 2) 쿠키의 구성요소는 키, 값, 유효 시간, 도메인 이름, 경로 등이 있다.
유효 시간을 명시하면 브라우저가 종료되더라도 명시한 기간동안 쿠키는 사라지지 않는다.
도메인 이름과 경로는 특정 도메인과 경로에서만 쿠키를 사용하도록 하는 옵션이다.
1 - 3) Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있다.
1 - 4) 쿠키는 만들어지기만 하면 브라우저가 자동으로 Request 시에 header에 넣어 서버에 전송한다.
물론 요청을 보내는 엔드포인트가 만들어진 쿠키의 옵션의 조건에 부합하는 경우만이다.
2. 쿠키는 왜 필요한가?
HTTP 통신 방식은 두 가지 특징을 가지고 있다.
2 - 1) Conectionless
클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징
HTTP는 먼저 클라이언트가 request를 서버에 보내면, 서버는 클라이언트에게 요청에 맞는 response를 보내고 접속을 끊는 특성
2 - 2) Stateless
통신이 끝나면 상태를 유지하지 않는 특징
연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성
이러한 두 가지 특성으로 쿠키가 필요한 것이다.
예를 들어, 어떤 사용자가 웹 애플리케이션을 이용하기위해 로그인을 했다.
만약 로그인을 했다는 정보가 저장되지 않는다면 해당 사용자는 웹 페이지를 이동할 때마다 매번 로그인을 해야할 것이다.
3. 쿠키 옵션
- Domain쿠키 옵션에서 도메인은 포트 및 서브 도메인 정보, 세부 경로를 포함하지 않는다.따라서 요청해야 할 URL이 http://www.localhost.com:3000/users/login 이라 하면 Domain은 localhost.com이 된다.
- 만약 쿠키 옵션에서 도메인이 존재한다면 클라이언트에서는 쿠키의 도메인과 서버의 도메인이 일치해야만 쿠키를 전송할 수 있다.
- 여기서 서브 도메인이란 www 같은 도메인 앞에 추가로 작성되는 부분을 말한다.
- 도메인이라는 것은 여러분들이 흔하게 보실 수 있는 www.google.com과 같은 서버에 접속할 수 있는 이름이다.
- Path만약 요청해야 하는 URL이 http://www.localhost.com:3000/users/login 인 경우라면 여기에서 Path,
Path 옵션의 특징은 설정된 path를 전부 만족하는 경우 요청하는 Path가 추가로 더 존재하더라도 쿠키를 서버에 전송할 수 있다. - 즉 Path가 /users로 설정되어 있고, 요청하는 세부 경로가 /users/login 인 경우라면 쿠키 전송이 가능하다.
- 명시하지 않으면 기본으로 / 으로 설정되어 있다.
- 세부 경로는 /users/login이 된다.
- 경로는 서버가 라우팅할 때 사용하는 경로다.
- MaxAge or ExpiresMaxAge는 앞으로 몇 초 동안 쿠키가 유효한지 설정하는 옵션이다.이후 지정된 시간, 날짜를 초과하게 되면 쿠키는 자동으로 파괴된다.
- 하지만 두 옵션이 모두 지정되지 않는 경우에는 브라우저의 탭을 닫아야만 쿠키가 제거될 수 있다.
- Expires 은 MaxAge와 비슷하다. 다만 언제까지 유효한지 Date를 지정한다. 이때 클라이언트의 시간을 기준으로 한다.
- 쿠키가 유효한 기간을 정하는 옵션이다.
- Secure 쿠키를 전송해야 할 때 사용하는 프로토콜에 따른 쿠키전송 여부를 결정한다. 만약 해당 옵션이 true로 설정된 경우, 'HTTPS' 프로토콜을 이용하여 통신하는 경우에만 쿠키를 전송 할 수 있다.
- HttpOnly만약 해당 옵션이 true로 설정된 경우, 자바스크립트에서는 쿠키에 접근이 불가능하다.만약 이 옵션이 false인 경우 자바스크립트에서 쿠키에 접근이 가능하므로 'XSS' 공격에 취약하다.
- 명시되지 않는 경우 기본으로 false로 지정되어 있다.
- 자바스크립트에서 브라우저의 쿠키에 접근 여부를 결정한다.
- SameSite사용 가능한 옵션은 다음과 같다.
- Lax :Cross-Origin 요청이면 'GET' 메소드에 대해서만 쿠키를 전송할 수 있다.
- Strict : Cross-Origin이 아닌 same-site 인 경우에만 쿠키를 전송 할 수 있다.
- None: 항상 쿠키를 보내줄 수 있습니다. 다만 쿠키 옵션 중 Secure 옵션이 필요합니다.
- Cross-Origin 요청을 받은 경우 요청에서 사용한 메소드와 해당 옵션의 조합으로 서버의 쿠키 전송 여부를 결정하게 된다.
이러한 옵션들을 지정한 다음 서버에서 클라이언트로 쿠키를 처음 전송하게 된다면 헤더에 Set-Cookie라는 프로퍼티에 쿠키를 담아 쿠키를 전송하게 된다.
이후 클라이언트 혹은 서버에서 쿠키를 전송해야 한다면 클라이언트는 헤더에 Cookie라는 프로퍼티에 쿠키를 담아 서버에 쿠키를 전송하게 된다.
4. Session
4 - 1) 세션은 쿠키를 기반하지만, 해당 데이터를 브라우저에 저장하는 쿠키와 달리 서버에 저장한다.
4 - 2) 서버에서는 클라이언트에게 고유한 세션 ID를 부여해 클라이언트를 식별한다.
4 - 3) 기본적으로 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다.
4 - 4) 사용자의 정보를 서버에 저장한다는 점에서 쿠키보다 보안성은 좋지만, 사용자가 많아질수록 서버에 과부하가 걸릴 수도 있다.
5. Session의 동작 방식
5 - 1) 클라이언트가 서버에 접속 시 세션 ID를 발급받는다.
5 - 2) 클라이언트는 세션 ID에 대해 쿠키를 사용해 브라우저에 저장한다.
5 - 3) 클라이언트는 서버에 요청할 때, 이 쿠키의 세션 ID를 서버에 전달한다.
5 - 4) 서버는 세션 ID를 전달 받아 서버에 저장된 세션 ID와 일치하는지 확인하고 세션에 있는 클라이언트 정보를 가져온다.
5 - 5) 클라이언트 정보를 가지고 서버 요청을 처리하여 클라이언트에게 응답한다.
6. 쿠키와 세션의 차이
6 - 1) 쿠키와 세션은 비슷한 역할을 하며, 동작원리도 비슷하다. 그 이유는 세션도 결국 쿠키를 사용하기 때문이다.
6 - 2) 가장 큰 차이점은 사용자의 정보가 저장되는 위치다. 쿠키는 서버의 자원을 전혀 사용하지 않으며, 세션은 서버의 자원을 사용한다.
보안 면에서 세션이 더 우수하며, 요청 속도는 쿠키가 세션보다 더 빠르다. 그 이유는 세션은 서버의 처리가 필요하기 때문이다.
6 - 3) 쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어 보안에 취약하다.
하지만 세션은 쿠키를 이용해 session_id 만 저장하고 그것으로 구분해서 서버에서 처리하기 때문에 비교적 보안성이 좋다.
6 - 4) 라이프 사이클, 쿠키도 만료시간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 계속해서 정보가 남아 있을 수 있다.
또한 만료기간을 넉넉하게 잡아두면 쿠키삭제를 할 때 까지 유지될 수도 있다.
6 - 5) 반면에 세션도 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제된다.
7. 캐시와 엄연히 다르다!
캐시는 정적파일을 브라우저나 서버 앞 단에 저장해놓고 사용하는 것이다.
한번 캐시에 저장되면 브라우저를 참고하기 때문에 서버에서 변경이 되어도 사용자는 변경되지 않게 보일 수 있다.
이런 부분은 캐시를 지워주거나 서버에서 클라이언트로 응답을 보낼 때 header에 캐시 만료시간을 명시하는 방법등을 이용할 수 있다.
'Authentication' 카테고리의 다른 글
| JWT (0) | 2020.12.15 |
|---|---|
| OAuth 2.0 (0) | 2020.12.04 |